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PREFACE 


The Hughes Aircraft Company Pioneer Venus final report is based on 
study task reports prepared during performance of the '^System Design Study 
of the Pioneer Spacecraft* These task reports were forwarded to Ames 
Research Center as they were completed during the nine months study phase. 
The significant results from these task reports, along with study results 
developed after task report publication dates, are reviewed in this final 
report to provide complete study documentation- Wherever appropriate, the 
task reports are cited by referencing a task number and Hughes report refer- 
ence number- The task reports can be made available to the reader specific- 
ally interested in the details omitted in the final report for the sake of brevity. 


This Pioneer Venus Study final report describes the following baseline 
configurations: 

• '*Thor/Delta Spacecraft Baseline’* is the baseline presented at 
the midterm review on 26 February 197 3. 

• ’^Atlas/Centaur Spacecraft Baseline” is the baseline resulting 
from studies conducted since the midterm, but prior to receipt 
of the NASA execution phase RFP, and subsequent to decisions 
to launch both the multiprobe and orbiter missions in 1978 and 
use the Atlas/Centaur launch vehicle. 

0 ’’Atlas /Centaur Spacecraft Midterm Baseline” is the baseline 

presented at the 26 February 197 3 review and is only used in the 
launch vehicle utilization trade study. 

The use of the International System of Units (SI) followed by other 
units in parentheses implies that the principal measurements or calculations 
were made in units other than SI. The use of SI units alone implies that the 
principal measurements or calculations were made in SI units. All conver- 
sion factors were obtained or derived from NASA SP-7012 (1969). 

The Hughes Aircraft Company final report consists of the following 
documents: 

Volume 1 - Executive Summary - provides a summary of the major 
issues and decisions reached during the course of the study. A brief 
description of the Pioneer Venus Atlas/Centaur baseline spacecraft 
and probes is also presented. 
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Volume Z - Science -* reviews science requirements, documents the 
science ^peculiar trade studies and describes the Hughes approach 
for science implementation. 

Volume 3 - Systems Analysis - documents the mission, systems, 
operations, ground systems, and reliability analysis conducted on 
the Thor/Delta baseline design. 

Volume 4 - Probe Bus and Orbiter Spacecraft Vehicle Studies - 
presents the configuration, structure, thermal control and cabling 
studies for the probe bus and orbiter. Thor/Delta and Atlas/Centaur 
baseline descriptions are also presented. 

Volume 5 Probe Vehicle Studies - presents configuration, 
aerodynamic and structure studies for the large and small probes 
pressure vessel modules and deceleration modules. Pressure 
vessel module thermal control and science integration are discussed. 
Deceleration module heat shield, parachute and separation/despin 
are presented. Thor/Delta and Atlas/Centaur baseline descriptions 
are provided. 

Volume 6 - Power Subsystem Studies 

Volume 7 Communication Subsystem Studies 

Volume 8 - Command/Data Handling Subsystems Studies 

Volume 9 ^ Altitude Control/Mechanisms Subsystem Studies 

Volume 10 - Propulsion/ Orbit Insertion Subsystem Studies 

Volumes 6 through 10 - discuss the respective subsystems for the 
probe bus, probes, and orbiter. Each volume presents the sub- 
system requirements, trade and design studies, Thor/Delta baseline 
descriptions, and Atlas/ Centaur baseline descriptions. ^ 

Volume 11 - Launch Vehicle Utilization - provides the comparison 
between the Pioneer Venus spacecraft system for the two launch 
vehicles, Thor/Deita and Atlas/Centaur. Cost analysis data is 
presented also. 

Volume IZ - International Cooperation - documents Hughes suggested 
alternatives to implement a cooperative effort with ESRO for the 
orbiter mission. Recommendations were formulated prior to the 
deletion of international cooperation. 

Volume 13 - Preliminary Development Plans - provides the 
development and program management plans. 
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Volume 14 - Test Planning Trades -documents studies conducted to 
determine the desirable testing abroach for the Thor/Delta space- 
craft system. Final Atlas/Centaur test plans are presented in 
Volume 13. 

Volume 15 - Hughes IRj^D Documentation - provides Hughes internal 
documents generated on independent research and development money 
which relates to some aspects of the Pioneer Venus program* These 
documents are referenced within the final report and are provided for 
ready access by the reader. 

Data Book - presents the latest Atlas/Centaur Baseline design in an 
informal tabular and sketch format. The informal approach is used 
to provide the customer with the most current design with the final 
report. 
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1. SUMMARY 


Study tasks for the command and data handling subsystems have 
been directed to; 

1) Determining ground data systems (GDS) interfaces and 
deep space network (DSN) changes, if required 

2) Defining subsystem requirements 

3) Surveying existing hardware that could be used or 
modified to meet subsystem requirements 

4) Establishing a baseline design 

Study of the existing GDS led to the conclusion that the Viking con- 
figuration GDS can be used with only minor changes required for the Pioneer 
Venus baseline. Those changes required are associated with providing a 
predetection recording capability used during probe entry and descent. 

Subsystem requirements were first formulated with sufficient latitude 
so that surveys of existing hardware could lead to low cost hardware which, 
in turn, could modify more narrowly defined subsystem requirements. 

To a large extent, existing hardware has been found that will meet 
performance requirements for the spacecraft subsystems. The hardware 
selected is largely from the OSO-I program, which provides equipment 
specifically developed for interfacing various scientific experiments for a 
space mission. Hardware for the large and small probe vehicles is mostly 
of new design, due to stringent weight, power, and volume limitations. 

There is a great deal of commonality between the large and small probes, 
and at the module level, many circuits come from the OSO-I program. 

Originally (as of the midterm presentation), there was little differ- 
ence in the command and data handling hardware developed for the Thor/ 
Delta or Atlas /Centaur versions of the program. Functional requirements 
and performance were identical in all respects. Boost vehicle payload 
limitations of Thor/Delta forced a different product design that made 
extensive use of LSI for new circuit designs. In addition, the large and 
small probe data rates and formats were different for the two versions 
due to different descent velocities. These were the extent of the differences. 
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The program decision to utilize the Atlas /Centaur launch vehicle 
rather than the Thor/Delta, and the coincident decisions to utilize the same 
launch opportunity for both the multiprobe and orbiter missions and change 
the science payload, necessitated some baseline changes in the mission and 
hardware designs which are summarized as follows: 

1) Two spacecraft in transit to Venus at same time - requires 
some means of assuring that the spacecraft can be separately 
addressed and commanded. Also requires separation of down- 
link frequencies and makes desirable a spacecraft identifier 
within the data stream. 

2) New science payload - due to the great increase in science 
data rates at periapsis, some changes in science data formats, 
spacecraft clock rates, and data storage accommodation have ' 
been required. 

The majority of the material and trade studies discussed in this 
report {Sections 4 and 5) were generated prior to the program changes dis- 
cussed above. In general, none of the trade studies were affected by launch 
vehicle selection considerations up until these program changes occurred; 
therefore, no general attempt has been made to update the trade studies 
with the affects described. The material contained in Section 6, however, 
does represent updated current baseline designs for the Atlas /Centaur 
1978 missions. 

Tables 1-1 to 1-3 tabulate the current Atlas /Centaur baseline 
characteristics and hardware source. 

The spacecraft command subsystem will handle over 192 pulse 
commands and 12 magnitude commands. A 16 bit magnitude command is 
utilized. The command memory can store 85 24- bit words. Each 
memory unit can represent pulse, magnitude, or time delay information. 

The command word length is 36 bits, which can accommodate either a real 
time magnitude command or a word of command memory data. 

The probe vehicles operate from commands stored in fixed sequences. 
Sequences of commands are initiated from a sequencer both as the result of 
the prestored timing sequence and/or the result of selected descent events 
(acceleration and pressure). The stored sequences include a short (15 min- 
ute) systems test to be used subsequent to separation from the launch 
vehicle; a long dormant coast phase (up to 21 days); preentry turn on; and 
descent sequence control. Pulse type commands, only, are initiated from 
the sequence. 

Data handling is required to acquire, encode, format, store, modu- 
late, and deliver data to the telecommunications subsystem for subsequent 
transmission to earth. Each spacecraft and probe vehicle produces a single 
composite telemetry stream for transmission to the earth. Prior to separa- 
tion from the probe bus, both the large and small probes provide composite 
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TABLE 1-1. SPACECRAFT MODULAR COMMAND SUBSYSTEM HARDWARE DERIVATION 

AND CHARACTERISTICS 


Unit (Quantity) 

Hardware Derivation 

Hardware Characteristics 

Atla s / C entaur 
Probe Bus 

Atla s / C entaur 
Orbiter 

Mass (Weight), 
kg (lb) 

Power, 

W 

Volume, 
cm (in ) 

Command demodulator (E) 

Motorola 

(Uses 98 percent 
Viking orbiter 
circuits; MSI) 

Same 

2.5 ( 5.6) 

3. 0 

3, 080 (188) 

Central decoder (E) 

New design 

(Uses 50 percent 
OSO circuits; 
MSI) 

Same 

4.3 ( 9.4) 

3.6 

6, 000 (366) 

Command output module (6) 
(remote decoder) 

OSO 

(six single 
units; existing 
LSI) 

Same 

1.8 (4. 2) 

0.3 

1, 720 (105) 

Pyro control unit (2) 

New design 

(Uses 70 percent 
existing circuits) 

Same 

1.2 (2.5) 

-0- 

4, 260 (260) 

Probe bus totals 
Orbiter totals 

9.8 (21.7) 

Same 

6.9 

Same 

15, 060(919) 
Same 




TABLE 1-2. SPACECRAFT MODULAR DATA HANDLING SUBSYSTEM HARDWARE 

DERIVATION AND CHARACTERISTICS 



Hardware Derivation 

Hardware Characteristics 

Unit (Quantity) 

Atlas / Centaur 
Probe Bus 

Atla s / C entaur 
Orbiter 

Mass 

(Weight), 

(lb) 

Power, 

W 

Volume 

3 3 

cm (in ) 

Data Input Module (3) 

OSO 

Same 

1. 1 

( 2.4) 

0.4 

900 ( 55) 

(remote multiplexer) 

(three dual 
units; existing 
LSI) 






PCM encoder (2) 

OSO 

Same 

3. 1 

( 6.8) 

2. 6 

3, 510 (214) 


(two single 
units; existing 
MSI) 






Telemetry processor (2) 

New design 

Same 

3. 6 

{ 8.0) 

5.7 

6, 770 (413) 


(Uses 70 percent 
OSO circuits; 
MSI) 



i 



Data storage unit (2) 

Not required 

Core memory- 
POV 

— 

— 

— 

- _ _ _ _ _ 



(Modified 

electronic 







memories 

design) 

9. 1 

(20. 0) 

3. 0 

9, 630 (588) 


Probe bus totals 

7. 8 

(17.2) 

8. 7 

11, 180 (682) 


Orbiter totals 

16.9 

(37.2) 

11.7 

20, 810 (1270) 


*Where two sets of values are given, the bottom line is for the orbiter spacecraft. 



















TABLE 1-3. PROBE COMMAND AND DATA HANDLING SUBSYSTEM 
HARDWARE DERIVATION AND CHARACTERISTICS 


■ — ' ' — 



Hardware Characteristics 



Unit 

Atlas / Centaur 
Hardware Derivation 

Mass (Weight), 
kg (lb) 

Power 

Cruise /Descent 
W 

Volume 
cm fin ) 

Large probe 







Command /data unit 

1 

New design, existing technology; 
MIC AM construction 

1,95 

(4,3) 

0. 04/8. 3 

2, 720 

(166) 

Pyro control unit 

New design, existing technology; 
50 percent probe bus circuits 

1. 18 

(2.6) 

(Transient only) 

1,330 

( 81) 

Acceleration switches (2) 

(1) Existing design; space qualified 
(1) Existing design; non- space qualified 

0.23 

(0.5) 

— - 

66 

(4.0) 

Pressure switches (2) 

Existing design, high reliability; 
non- space qualified 

0. 18 

(0.4) 

--- 

25 

(1.5) 

Total 


3.54 

(7,8) 

0.04/8.3 

4, 140 

(253) 

Small probe 







Command /data unit 

New circuit design; 70 percent large 
probe circuits 

New product design; MICAM 
construction 

!, 54 

(3.4) 

0. 04/4. 6 

2. 280 

(139) 

Regulator unit 

New package, existing circuit 
design 

0. 18 

(0.4) 

O.O/I, 2 

L 

197 

( 12) 

Pyro control unit 

New circuit design; 80 percent large 
probe circuits 

New product design 

0, 55 

(L2) 

(Transient only) 

361 

( 22) 

Acceleration switches (2) 

(1) Same as large probe; space 
qualified 

(1) Existing design; non- space qualified 

0. 23 

(0.5) 

— 

66 

(4.0) 

Pressure switches (2) 

(1) Same as large probe 

(1) Existing design, high reliability; 
non- space qualified 

0. 18 

(0.4) 

■ 

25 

(1.5) 

Total 


2. 68 

(5.9) 

0. 04/5. 8 



2, 930 

(179) 





telemetry streams which can be summed and transmitted to Earth via the 
probe bus telecommunications subsystem. 

Data is telemetered as 8 bit words. The words are grouped into 
minor frames of 32 words and major frames of 16 minor frames. The 
configuration of any minor frame (data points to be sampled) is determined 
by a read-only memory in the telemetry processor. For the probe bus, there 
are nine different minor frames, for the orbiter there are 12. Selection and 
order of the 16 minor frames within a major frame is determined by ground 
command. 

The spacecraft telemetry processor contains 16 different major 
frames; any one of which may be selected by ground or stored command. 

The identification of the format selected is telemetered as part of each frame. 
Data rates are in multiples of 2^ between 8 and 2048 bps, depending on the 
mission phase and rf link margin. Capability is provided to store one 
telemetry format and transmit another to ground in real time. 

Data for the probes is telemetered as 10-bit words. In order to 
maximize the science data return within the available data bandwidth, 
engineering and science housekeeping data subcommutators are provided. 
There are two data formats for each probe type. 

Data rates for the large probe are 160 bps which is switched to 
80 bps at 20 km from the surface. Rates of 60 bps, 30 bps, and 10 bps are 
implemented for the small probe. These are switched during the descent 
sequence to conform to the rf link transmission capability. 

A data storage capability is provided on the orbiter spacecraft to 
gather data at rates exceeding the prevailing telecommunications capability 
and during planetary occultations when data transmissions are interrupted. 
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2. INTRODUCTION 


The command and data handling subsystems' basic functions are 
commanding and receiving data from the science instruments, and general 
operation of the orbiter and multiprobe missions. Low cost configurations 
that meet subsystem requirements are a design goal. 

The subsystems must accommodate science instrument command and 
data requirements. Flexibility must be incorporated into the design because 
of possible changes in the science instruments. Minimum changes in the DSN 
and other elements of the GDS are desirable; therefore, the subsystems must 
have a high degree of compatibility. The complete Pioneer Venus system 
should be easy to operate; thus, complexity must be minimized. 

The central design of the subsystems should be based on the use of 
existing, proven hardware. This will minimize costs. Where off-the- 
shelf hardware cannot be used or modified to meet requirements, new designs 
should be directed to simple elements and simple logic to provide a low cost 
implementation. 

An outline of the general studies performed for the command and 
data handling subsystems is presented in Table 2-1. A summary of these 
studies follows in subsequent sections of this volume. Requirements are 
summarized in the following section. The next section is devoted to the 
major subsystem trade studies which have been performed. 

Command subsystem studies include command interface, execution 
and storage, and probe cruise timer. Data handling subsystems studies 
include interface, probe and orbiter data storage and probe stored data 
playback techniques, multiple data formats and multiple data rates. 

Available subsystem hardware is then described. Subsequent sec- 
tions contain discussions of the receiver selection technique, and various 
aspects of the pyrotechnics and their control. Finally, the results and 
conclusions of a study investigating use of a programmable on-board data 
processor are presented. 

Command and data handling subsystems baseline designs have been 
established for both Thor/Delta and Atlas/Centaur boosted missions. Details 
of these baselines can be found in Sections 5 and 6 of this volume. The cur- 
rent subsystem baseline is described in Section 6, Section 5 represents the 
midterm Thor/Delta baseline, which has not been updated due to the program 
decision to utilize the Atlas/ Centaur launch vehicle. 
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TABLE 2-1. STUDY OUTLINE 


1 

Task 

No. 

Task 

Hughes Report 
Ref. Number 

CC 

Command /Control 


CCl 

Preliminary command list preparation 

HS-507-0022-73 

CC2 

Analyze command storage requirements 

Final Rpt 

CC3 

Command modulation techniques and 
message formats 

Final Rpt 

CC6 

Command interfaces with experiments 

HS-507-0022-148 

CC7 

Probe stored sequence requirements 

Final Rpt 

CCS 

Analyze prevention of inadvertent 
irreversible command execution 

HS-507-0022-68 

CC9 

Command subsystem functional design 

Final Rpt 

DH 

Data Handling 


DHl 

Data storage requirements 

Final Rpt 

DH2 

Use of central programmable processor 

Final Rpt 

DH3 

Multiplexer and analog /digital converter 
requirements 

Final Rpt 

DH4 

Evaluate digital interface designs 

HS-507-0022-149 

DH5 

Probe data storage 

HS-507-0022-38 

DH6 

Probe data rate 

HS-507-0022-37 

DH7 

Probe data handling frame optimization 

Final Report 

DH8 i 

Data handling list preparation 

Final Report 

DH9 

Bus data handling format requirements 

Final Report 

DHl 2 

Data handling subsystem functional 
design 

Final Report 



3. SUBSYSTEM REQUIREMENTS 


Requirements for command and data handling subsystem performance 
have been established by considerations of compatibility with the Deep Space 
Network (DSN), commanding of and receiving data from the science instru- 
ments, and operability of multiprobe and orbiter missions. The following 
subsections summarize the command and data handling subsystem perfor- 
mance requirements. This summary is based upon the Thor /Delta mission 
and baseline performance as defined in the midterm presentation. Updated 
or changed requirements based upon the current Atlas /Centaur configura- 
tion are available in Subsection 6. 1. 

The requirements presented here are the end product of successive 
iterations performed in the selection of the baseline configurations. Pre- 
liminary design on the basis of general trade studies and hardware surveys 
then resulted in a system outline, with more specific requirements. These 
requirements, in turn, were used in detailed trade studies leading to the 
system design. The requirements summarized in this section are generally 
those utilized for the trade studies and for the midterm baseline. 


3. 1 PROBE BUS AND ORBITER COMMAND REQUIREMENTS 

The command subsystem shall demodulate, decode, and distribute 
ground commands to enable control of the spacecraft. It shall store com- 
mands and associated time delays for later execution in order to implement 
spacecraft control during periods when real time control is not possible 
(e. g. , before initial acquisition and during orbiter occultation). Modulation 
shall be PCM/PSK/PM or PCM/FSK/PM for DSN compatibility. Command 
bit rates shall be 1, 2, 4, or 8 bps to minimize command times at varying 
mission communications distances and remain within the DSN allowable 
rates of 1 to 8 bps. The command word length shall be 3 6 bits, which is 
compatible with the DSN requirement of < 72 bits and satisfies addressing, 
magnitude size, and timing requirements. Realtime and stored commands 
shall be executed with a resolution of ±0. 125 sec. Command execution error 
contribution due to timer inaccuracy for stored commands shall be less than 
±0. 125 sec/hr resulting in a total error of < 0- 375 sec after a 2 hr delay 
(required at orbiter orbit insertion). Maximum stored time delay shall be 
< 4 hr. 
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TABLE 3-1. SPACECRAFT COMMAND ASSIGNMENTS 


Subsystem 

Pulse 

Magnitude 

Interlocked 

Probe Bus: 




Command 

7 

2 

0 

Communications 

18 

0 

0 

Control and propulsion 

17 

1 

1 

Data handling 

6 

3 

0 

Power 

60 

0 

0 

Probes 

12 

4 

4 

Science 

18 

0 

2 


138 

10 

7 

Orbiter: 




Command 

7 

2 

0 

Communications 

16 

0 

0 

Control and propulsion 

31 

4 

3 

Data handling 

9 

3 

0 

Power 

69 

0 

0 

Science 

41 

1 

2 




‘ 


173 

10 

5 


/ 


3,-2 














Commands shall be of three types: 

1) Pulse -required for on/off switching 

2) Magnitude-required for transferring serial data 

3) Interlocked-required for added safety against inadvertent 
execution of critical functions (squib firing, thrusting, etc. ) 

Numbers of commands required are presented in Table 3-1. The serial 
data portion of the magnitude command shall be 16 bits as required for 
memory loading and attitude control data transfer. 

Memory word size shall be 24 bits to accommodate command 
addressing, word identifier, and serial data requirements. The total num- 
ber of memory words (command or time) shall be 64, per anticipated stor- 
age requirements at orbit insertion. 

Overall command subsystem requirements are summarized in 
Table 3-2. 

Command Word Format 


A 22 bit command word format was considered in the initial study 
phases since it could have been compatible with existing Pioneer software 
and some existing hardware. Further study of command requirements 
revealed that a 22 bit word was undesirable to satisfy addressing require- 
ments, particularly with regard to memory fill and other magnitude com- 
mand requirements. DSN command word requirements dictated that the 
efficient command word be of length S 72 bits. A 3 6 bit word was selected 
for the reasons that it satisfies spacecraft command requirements, and is 
largely compatible with existing OSO command hardware. It results in 
simplified spacecraft command subsystem operations since only one magni- 
tude command is now required to fill a memory word or transfer enough bits 
to satisfy subsystem serial data requirements. The selected format is the 
following: i 


Sync 

1 

1 

1 

RD 

Sel 

1 

NRZ 

Pulse Command Select Or 
Data To Be NRZ Transferred 

Polynomial 

Code Check 

... 

1 4 5 

t 

6 7 

n 

8 10 1^ 

12 13 14 29 30 36 

- "P u 1 s e/ M agnit ud e 
Time/ Command Data 


Stored/Real Time 

Central Decoder Select 
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TABLE 3^2. COMMAND SUBSYSTEM REQUIREMENTS 


Multiprobe bus 

Demodulate, decode, distribute ground commands 

Store commands for later execution, 17 words minimum storage 

PCM/PSK/PM or PCM/FSK/PM 

1, 2, 4, or 8 bps command rate 

36 bit command word 

Pulse commands: 

120 engineering 
18 experiment 

Magnitude commands: 

10 engineering 

Interlocked commands: 

7 engineering 

Threshold 

1 X 10"^ BER 

Probability of executing false command at threshold 

1 X 10'^ 

Orbiter 

Demodulate, decode, distribute ground commands 

Store commands for later execution, 25 words minimum storage 

PCM/PSK/PM or PM/FSK/PM 

1, 2, 4, or 8 bps command 

36 bit command word 

Pulse commands; 

132 engineering 
41 instrument 

Magnitude commands: 

9 engineering 

1 instrument 

Interlocked commands: 

3 engineering 

2 instrument 

Time 

10 sec in 24 hour 
0. 5 sec in 1 hr 

Threshold 

1 X 10‘^ BER 

Probability of executing false command at threshold 
1 X 10'*^ 
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Command bit 
Bits 
1 to 4 

5 

6 

7 

8 to 10 
11 

12, 13 
14 to 29 

30 to 36 


assignments are the following: 

F unction 


Sync 

Central decoder select 

Indicates whether remainder of word is to be 
stored or used in real time 

Indicates whether bits 14 to 29 are command or 
time information if the word is going to storage 
(the "time" indication is not allowed if bit 6 
indicates "real time") 

Addresses 1 of 8 remote decoders (All 8 need not 
be used) 

Indicates whether bits 14 to 29 address 1 of 64 
pulse command lines at a remote decoder, or 
are to be transferred as serial data 

Addresses 1 of 4 lines from remote decoder 
over which serial data is to be transferred 

Addresses 1 of 64 pulse command lines at a 
remote decoder, or contains 16 bits of serial 
data to be NRZ transferred 

Used in the polynomial check to detect as a 
minimum any one of two bit errors occurring 
in bits 5 through 29 
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DSN Imposed Requirements 

Table 3-3 summarizes the pertinent spacecraft DSN support 
requirement and the DSN capability. 

The DSN command system employs either FSK or PSK modulation. 

Subcarrier frequency is constrained to lie between 100 Hz and 
1. 0 MHz with 0. 1 Hz resolution. A subcarrier frequency of 512 Hz is 
selected based upon existing hardware requirements. 


DSN compatible data rates are 1 to 8 bps with a resolution of 
1 X 10“5 bps. Data rates of 1, 2, 4, and 8 bps are compatible with mission 
requirements and communications capabilities, and are therefore selected 
as baseline. Resulting memory fill times are the following (assuming an 
85 word X 24 bit memory). 

Bit Rate 

1 
2 
4 
8 

DSN uncertainty in the transmission of command information for 
PSK modulation is 1 bit time. 


Fill Time 

5 1 min 
25. 5 min 
12, 75 min 
6. 375 min 


The maximum time required to reconfigure the DSN command sub- 
system is < 30 min. 

An idle sequence of any repetitive modulo 24 bit pattern or subcar- 
rier only can be generated at any DSS. 


TABLE 3-3. DSN SUPPORT REQUIREMENTS - COMMAND 


F unction 

Spacecraft Requirement 

DSN Capability 

• Subcarrier frequency 

TBD 

100 Hz to 
1 . 0 MHz 

• Type 

Biphase PSK or FSK 

PSK or FSK 

• Rate 

1, 2, 4, 8 bps 

1 to 8 bps 

• Word length 

36 bits 

<72 bits 
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3. 2 PROBE COMMAND REQUIREMENTS 


Mission Imposed Requirements 

Th.e probe mission consists of a. cruise period aboard the probe bus 
spacecraft for approximately 100 days. At 20 days before entry the probes 
are released from the spacecraft at which time they begin operations from 
an onboard sequencer. During the 100 day preseparation cruise phase probe 
test events are controlled by commands into the probe from the bus. There 
are five such commands for each probe: 

1) Start probe test 

2) Stop probe test 

3) Start probe timer 

4) Stop probe timer 

5) Load probe timer (magnitude) 

Following separation, control is from the sequencer that issues commands 
at a preprogrammed time, or upon sensing an event. 

Timing Requirements 


Timer resolution and accuracy are determined by the mission 
requirement to apply power to probe subsystems following the 20 day coast 
to within ±20 sec of the desired time. Postentry timing requirements 
delineated in Tables 3-4 and 3-5 are less constraining than the above 
requirement. 

Command Generation Require ments 

Science data reception and probe spacecraft control requirements 
dictate the large and small probe descent command sequences presented in 
Tables 3-4 and 3-5, respectively. Overall command generation require- 
ments are summarized below: 


Events 

Large probe 27 

Small probe 7 


Number of Commands 
43 
15 


Total Commands Issued 
77 
25 
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TABLE 3-4. LARGE PROBE DESCENT COMMAND SEQUENCE 


Subsequence 

Time 

Commands 

Initiated By 

Timer 

initiation 

R+0 

£-20^^ 


Bus command 

Postsepara- 
tion test 

S+0 

E-20'^ 

Engineering 
electronics -On 
RF-On 

Separation 

switch 

End test 

s+io”^ 

±5® 

Sep+lO”^ 

RF-0££ 
Engineering 
electronics -Off 

Timer delayed 10^ 
from separation 
switch 

Pre-entry I 

i 

! R+JS'^ 
±lh 

£-2^^ 

1 

Engineering 
electronics -On 
Planet flux 
heater -On 
Engineering 
electronics -Off 

Timer 

Pre- entry II 

R+20^ 
±20 s 
= P+0 

E-15^ i 

Engineering i 

electronics -On 
RF-On 
Sensor s -On 

Timer 

Pre- entry III 

P+10“ 

±1>^ 

E-5^ 

Level II set 
Deceleration 
module -On 
Format I 
select 
Data rate I 
select 

Timer 

Blackout I 

B+0 

E+5® 

Format II 
select 

Data rate II 
select ' 

Re- initiation | 

timer 

0. 5 g switch 

Blackout II 


E+6® 

Arm monitor 
Re -initialize 
timer (burn) 

3, 0 g switch 
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Table 3-4 (continued) 


Subsequence 

Time 

Commands 

Initiated By 

Postblackout 

B+IO® 

±is 

E+15® 

Format II 
select 

Data rate III 
sele ct 

Deceleration 

module-Off 

Timer 

3g switch 
closure 

C+0 

E+21® 

Re-initialize 

timer 

3g switch 
Timer switch 

Chute deploy 

C+4^ 
±0. IS 

E+25® 

PCU-On 
Fire chute 
deploy squibs 

Timer 

Interface 

disconnect 

C+5® 
±0. 1® 

E+26® 

Fire IPD 
squibs 

Timer 

Aeroshell 

jettison 

C+5. 5® 
±0. IS 

E+26. 5® 

Fire jettison 
squibs 

Time r 

Des cent 

C+6® 
±0. 1® 

E+27® 

Format IV 
select 

Data rate IV 
select 
Level II set 
Science-On 
Window heater - 
On 

Fire breakoff 
hat 

PCU-Off 

Timer 

i 

Chute 

jettison 


E+9, 6^ 

PCU-On 
Fire chute 
jettison squibs 
PCU-Off 
Step up mass 
spectrometer 
power 

0, 5 Atm pressure 
switch 

Window 

jettison 

C+14. 2^ 
±8.0"^ 

E+14. 5”^ 

PCU-On 
Fire window 
jettison squibs 
PCU-Off 

Timer 
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Table 3-4 (continued) 


Subsequence 

Time 

Commands 

Initiated By 
^ 

Data rate 
reduction 


E+28; 

Data rate II 
select 

Level III set 

25 Atm, pressure 
switch 

Impact 

0+53. 7^ 

±1. orn 

E+51. z!^ 

F o rmat I 
select 

Window heater - 
Off 

Planet flux 
heater -Off 
Sequencer -Off 

Timer 

Mass spec- 
trometer 
events 



Ten of the 
following: 
PCU-On 
Fire inlet 
valve squib 
PC U- Off 

Mass spectrometer 
(asynchronous com- 
mand generation 
possibly coincident 
with other events) 


3, 3 PROBE BUS AND ORBITER DATA HANDLING REQUIREMENTS 

Two constraints on data system xequirements and design have been 
DSN compatibility and science experiment data requirements. The impact 
of these constraints and the trade study results are summarized in the fol- 
lowing paragraphs. 

Table 3-6 summarizes the overall spacecraft data handling require- 
ments for the probe bus and for the orbiter. 

Table 3-7 summarizes the assignment of engineering and science 
telemetry data channels to minor frames on the probe bus and orbiter. 

These assignments are required to meet engineering and science data 
sampling requirements. 

Table 3-8 provides telemetry mode (or major frame) configurations 
that are required to meet data sampling requirements at critical mission 
phases. 

DSN Compatibility 

Requirements for DSN compatibility and associated spacecraft 
' parameters are summarized in Table 3-9. The prime requirement has been 
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TABLE 3-5. SMALL PROBE DESCENT COMMAND SEQUENCE 


Subsequence 

T ime 

Commands 

Initiated By 

Timer 

initiation 

R+O 

E-20^ 


Bus command 

Magnetic + rf 
calibration 

S+0 

E-20^ 

Engineering 
electronics -On 
RF-On 
Science -On 
Format I select 

Separation switch 

End test 

S+10^ 

±5S 

Sep+10^ 

Science -Off 
RF-Off 
Engineering 
ele ctronics -Off 

Timer delay 10^^ 
after separation 

Pre- entry I 

R+ZO'^ 
±2. QS 

E-45*^ 

Engineering 
electronics -On 

Timer 

Pre -entry II 

R+ZO'^ 
±2. QS 

E-15"^ 

RF-On 
Science-On 
PCU-On 
Fire despin 
thrusters 
PCU-Off 

Timer 

Pre-entry III 

d 

R + 20 ' 

±2.0® 1 

E-2”^20® 

Format II 
select 
RF-Of£ 

Timer 

Descent 

D+0 ! 

! 

E+19. 5® 
to 

E+3 2. 5”" 

RF-On 

Format I select 
Window heater- 
On 

PCU-On 

Fire temperature 
probe / nephelom- 
eter cover squih 
PCU-Off 

Re-initialize timer 

2. 0 g switch 

Impact 

D+74"" 

±im 

E+74. 2”^ 
to 

E+74. 9”^ 

Window heater - 
Off 

Format II science 

Timer 
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TABLE 3-6. OVERALL SPACECRAFT DATA 
HANDLING REQUIREMENTS 


Multiprobe bus 

Multiplex, format, encode and modulate spacecraft and 
experiment data 

PCM/PSK/PM 

Convolutional encoding 

8 to 2048 bps data rates 

Data frames: 

9 frames: 32, 8 bit words 

Operating modes: 

Real time 

Formats {four nominal frame combinations; variations 
selectable on command) 

Cruise science (16 to 84 bps) 

Entry science (2048 bps) 

Thruster firing (8 to 128 bps) 

Engineering interrogation (16 to 64 bps) 

Engineering channels 
113 analog 
13 serial digital 
98 discrete 

Experiment channels 
3 1 analog 
13 serial digital 
1 discrete 

Orbiter 

Multiplex, format, encode, and modulate spacecraft and 
experiment data 

PCM/PSK/PM 

Convolutional encoding' 

8 to 2048 bps data rate 

Data frames: 

12 frames; 3 2, 8 bit words 
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Table 3-6 (continued) 


Operating modes: 

Real time 
Stored 

Stored and real time 

Memory readout 

Memory readout and real time 

Formats (nine nominal frame combinations; variations 

selectable on command) 

Cruise science (16 to 64 bps) 

Apoapsis science (2) (64 to 128 bps) 

Periapsis science (64 to 128 bps) 

Store (3) (5 to 428 bps) 

Thruster firing (8 to 128 bps) 

Engineering interrogation U6 to 64 bps) 

Engineering channels 
137 analog 
1 0 serial digital 
46 discrete 

Experiment channels 
7 analog 
5 serial digital 
1 discrete 

361 kilobits data storage 


to minimize changes to the DSN and to be compatible with the multimission 
capability so that data from the spacecraft can be processed in real time 
and transmitted over high speed data lines (HSDL) to the ARC Pioneer 
Mission Operations Center (PMOC). Except for the requirement to provide 
predetection recording capability for probe entry and descent (discussed in 
Volume 3), no changes are required in the DSN. 

Subcarrier frequency selection was accomplished on the basis of DSN 
and bit rate compatibility and requirements of available transmitter hard- 
ware. As noted in Table 3-9 the DSN compatibility is basically between 20 
and 45 kHz. The spacecraft subcarrier is selected at 16 times this maxi- 
mum bit rate of 2, 048 bps. Probe subcarrier frequencies are selected 
above 20 kHz (the minimum capability of the selected, available hardware 
transmitter) and at frequencies of integer multiples of the bit rates. Modu- 
lation type PCM/PSK/PM is dictated by the DSN MMC. 
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TABLE 3-7. MINOR FRAME DATA CHANNEL ASSIGNMENTS 


Common to Probe Bus and Qrbiter Spacecraft 
Engineering A, B, C, D 

IW 29W (Frame Words) 



FRAME 


SYNC 

ID 

ENGINEERING HOUSEKEEPING 


TCM A, B 

2W IW 29W (Frame Words) 



FRAME 


SYNC 

ID 

ENGINEERING HOUSEKEEPING 


CMR (Command Memory Recycle) 


2W IW 14W 14W IW (Frame Words) 



FRAME 

MEMORY 

MEMORY 


SYNC 

ID 

A 

B 

SPARE 


Qrbiter Spacecraft 
SCI A 


2W rw 7W 7W 8W 7W (Frame Words) 



FRAME 





SYNC 

ID i 

MAGN 

SOLAR WIND 

UV SPECT 

SPARE 







SI- 


Table 3-7 (continued) 


Qrbiter (Continued) 


SCI B (Housekeeping) 


2W 

IW 

IW 

IW 

IW 

IW 

IW 

IW 

IW 

IW 

1 w 

SYNC 

FRAME 
ID # 

MHl 

MHZ 

MH3 

MH4 1 

LPHl 

LPH2 

LPH3 

NMSHl 

NMSH2 


IW 

IW 

IW 

IW 

IW 

IW 

IW 

IW 

IW 


NMSH3 

NMSH4 1 IMSHl | IMSH2 1 

IMSH3 

UVSHl 

1 UVSH2 

UVSH3 

UVSH4 


IW 

IW 

IW 

IW 

IW 

IW 

1 W 

IW 

1 W 

1 

1 UVSH5 1 UVSH6 

1 IRRHl 1 IRRH2 1 

IRRH3 1 IRRH4 

1 SWHl 

SWH2 

T SWH3 


IW 


SWH4 


IW 


SPARE 


(Frame 

Words) 

(Frame 

Words) 

(Frame 

Words) 


CM 


SCI C 


2W 

IW 

IW 

8W 

4W 

4W 

2W 

IW 

5W 

4W 

i 










SYNC j 

ID # 1 

MAGN 

LANG PROBE 

IMS 

UVS 

IRR 

SW 

NMS 

SPARE 


(Frame 

Words) 


SCI D 


2.W IW 4W 16W 4W 5W 


SYNC 


T'R'AME 
ID # 


SW 


SPARE 


MAGN 


uvs 


(F rame 
Words) 
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Table 3-7 (continued) 


SCI E 


2W 

IW 

25W 

IW 

IW 

IW 

IW ^ 

SYNC 

FRAME 
ID # 

RADAR ALTIMETER DATA 

RAHl 

RAH2 

RAH3 

RAH4 


(.Frame 

Words) 


Probe Bus 

SCI A (Cruise Science) 


2W 

IW 

22W 

2W 

IW 

IW 

IW 

IW 

IW 

SYNC 

FRAME 
ID # 

MAGN 

MHl 

MH2 

MH3 

MH4 

MH5 

SPARE 


SCI B (Encounter Science) 


(Frame 

Words) 


2W 

IW 

6W 

5W 

2W 

2W 

IW 

IW 

IW 


IW 

IW 

IW 

SYNC 

FRAME 
ID # 

NMS 

IMS 

LP 

UVF 

M 

MHl 

MH2 

MH3 

MH4 

MH5 



IW 

IW 


IW 

5W 

(Frame 





IMSHl 

IMSH2 

IMSH3 

SPARE 


Words) 


(Frame 

Words) 







-17 


TABLE 3-8. NOMINAL TELEMETRY MODES 


w 


Mode 


2 

3 

4 

5 

6 

7 


2 

3 

4 


Description 


Probe bus engineering 
instruments 


TCM 

Attitude determination 

Cruise science 

Engineering instru- 
ments - cruise 
s cience 

Science encounter 

Computer memory 
recycle 

Orbiter engineering 


TCM 

Attitude determination 
Cruise science 


Rates, bps 


Science 

Requirement 


13 

13 

220 


Nominal 


16 

16 

2048 


16 


Minor Frame Sequence 


I ENG A, B, C, D TCM 
A, B 

Spare, Spare 
8 X TCMA, TCMB 
16 X TCMA 
16 X SCI A 

Mode 1 decks alternated 
with mode 3 decks 

16 X SCI B 
16 X CMR 


2 X 


ENG A. B, C, D 
TCMA B 


[spare. Spare 
8 X TCMA, TCMB 
16 X TCMA 
2 X SCI B, 7 X SCI A 
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Table 3-8 (continaed) 




Rates, 

bps 



Mode 

Description 

Science 

Requirement 

Nominal 


Minor Frame Sequence 

5 

Engineering instru- 
ments - cruise 
science 

9 

16 


Mode 1 decks alternated 
with mode 3 decks 

6 

Apoapsis 

19 

128 

( 32)>i< 


ISCI B, 4 X SCI D, 

ENG A, B, C, D TCM A, 
I B 5 spares 

7 

Apo apsis - playback 

19 

128 

( 32)^:= 


SCI B, 4 X SCI D, TCMA, 
B 

ENG A, B, C, D, five 
Stored Decks 

8 

Periapsis 

86 

128 


SCI B, 15 X SCI C 

9 

Computer memory 
recycle 

1 

-- 


16 X CMR 

10 

Apoapsis 

19 

128/64 

(64/32)* 

1 

[SCI B, 7 X SCI D, ENG A, 
B, C, D 

[TCM a, B, 4 spares 

11 

Apoapsis playback 

19 

128/64. 
(64/32)* 
(Playback 
= 64/32) 

1 

SCI B, 7 X SCI D, 
Eight stored decks 


( )* = 


Effective science data rate 



TABLE 3-9. DSN SUPPORT REQUIREMENTS - TELEMETRY 


F unction 

Requirement 

DSN Capability 

Subcarrier frequency 



• Spacecraft 

32, 768 kHz 

20 Hz < capability < 45 kHz 

Bit. rates, bps 
• Spacecraft 

8 to 2048 


Sequential decoding 



• Constraint length, bits 

32 

32 

• Rate 

0. 5 

0. 5 

• Tail, bits 

> 20 

8 to 48 

• Frame length, bits 

s 640 

1200 


Additional Studies 


At the time of the midterm presentation specific analog conversion 
requirements had been established for the probe mission. These included 
10 bit resolution for some instruments and 7 bit for others. However, for 
the probe bus and orbiter spacecraft no specific requirements were given 
and capability was established on the basis of existing hardware. This cri- 
teria was utilized to minimize cost, and hardware was found that provided 
conversion resolution to 6. 7, and 8 bits. This included hardware from 
Pioneer, Mariner, and the OSO Programs. Other criteria, which included 
cost control, science instrument accommodation, etc. determined the hard- 
ware selection process. These are discussed in Section 4; however, the 
OSO program hardware was selected which provides an 8 bit analog-to- 
digital conversion resolution. It was felt that there was no specific require- 
ment for 8 bit resolution; however, some advantage might be gained from an 
8 bit system due to ground computer compatibility and the possibility of 
increased scientific instrument accuracy which would perhaps minimize 
experiment hardware. The May 1973 science instrument update did specify 
8 bit conversion accuracy for most scientific instruments on the probe bus 
and orbiter. Ten bit resolution was specified for two signals on the probe 
bus. Since this resolution requirement applies only to a single scientific 
instrument, and the existing OSO data handling hardware must handle all the 
science instrument's requirements, it is not planned to change the spacecraft 
to a ten bit system. Rather, the optimistic solution at this point is to require 
the instrument itself to perform ten bit conversions. ^ 


3-19 




Data compression techniques were briefly examined but eliminated 
as a requirement due to increased cost, weight, and ground data processing 
complexity* To be a viable consideration the data compression would have 
to permit elimination of a power amplifier in the RF telecommunications 
subsystem and this was not possible for any of the multiprobe or orbiter 
missions* 

Convolutional encoding techniques were also examined* At the time 
of the midterm, sequential decoding was required at the DSN due to hard- 
ware limitations* For this reason, the Pioneer 32 bit, quick look was 
selected for the baseline. Since the midterm, the decision to Launch in the 
1978 launch opportunity has permitted use of Viterbi decoding capability at 
the DSN. From the spacecraft standpoint, there is a weak preference for 
the Viterbi decodable class of convolutional codes* This is due to hardware 
simplicity associated with shorter constraint lengths and elimination of the 
tail sequence requirement. 


3. 4 PROBE DATA HANDLING REQUIREMENTS 

This subsection describes the requirements for the probe data handling 
subsystems. Table 3-10 summarizes the data handling requirements for, the 
large and small probes. 

Table 3-11 summarizes the assignment of engineering and science 
telemetry data channels to telemetry formats on the large and small probes* 
These assignments are required to meet engineering and science data 
sampling requirements* 

Derivation of Probe Data Handling Requirements 

The mission unique requirement has been to maximize the arnount of 
data that can be sampled and transmitted daring probe entry and descent* A 
small amount of data storage is required during the blackout (ion sheath) 
portion of entry* During the early study phase, subsystem weight presented 
the most critical design factor, and data formats and rates were carefully 
and efficiently ’’tuned^' to science payload requirements to eliminate unneces- 
sary Logic. Logic minimization has been a continuing goal, but (in view of 
the Atlas / Centaur Launch vehicle selection) the forcing function has shifted 
from weight to cost considerations. 

Each payload update for the probe missions has required establish- 
ment of new data formats and rates. It can be seen that these changes will 
continue until selection of the final payload. These changes, however, have 
been accommodated within the framework of the baseline design. This design 
allows flexibility in selection of input signal type (analog or s erial- digital) , 
data rates (simple countdown chain pickoff) , or formats. 
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TABl^E 3-10. PROBE DATA HANDLING REQUIREMENTS 


Large probe 

Format , encode and modulate spacecraft and experiment 
data 

PCM/PSK/PM 
Convolutional encoding 
276/184 bps data rate 

3 descent data formats (plus 1 landed data format) 

10 bit word size 

Engineering channels 

15 analog; 2 serial digital; 19 discrete 

Experiment channels 
58 analog 

4 serial digital; 9 discrete 
4096 bits data storage 
Small probe 

Format, encode and modulate spacecraft and experiment 
data 

PCM/PSK/PM 
Convolutional encoding 
15 bps data rate 
2 data formats 
10 bit word size 

Engineering channels - 13 analog; 2 serial digital; 

19 discrete 

Experiment channels 
12 analog 
2 serial digital 

480 bits data storage 
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TABLE 3-11. PROBE TELEMETRY FORMAT ASSIGNMENTS 


Large Probe 


De s cent I and II 


3 


Words 

2W 

22W 

41W 

17W 

5W 

3W 

2W 

33W 

Sync + 
ID 

Temp 

S 

Mass 

Spect 

Cloud 

Part 

AU 

Ext 

Nep 

Hygro 

Play 

Back 

Sub-Corn 


{Frame 

Words) 


Descent 1 (Sub Com Frame) 


IW 

IW 

4W 

4W 

3W 

20W 

20W 

2W 

19W 

2W 

2W 

2W 

Sync 

ID 

Temp 

ACC 

Press 

s 

Tur 

Solar 

Flux 

Planet 

Flux 

Trans 

Engr 

Nep 

Mass 

Spect 

Play 

Back 


6W 1 33W low 3W 



^ -r 

SAME AS DESCENT I SUB COM 

’ I 


44W 
Mass 
S p e c t 


(Frame 

Words) 


(Frame 

Words) 


M 
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Table 3-11 (continued) 


Landed and Store 2 


2W 


Sync 
+ ID 


30W 


Accelerometer Data 


(Frame 

Words) 


Store 




2W 

17W 

9W 

4W 

Sync 
+ ID 

Shock 
Layer Rad 

Accelerometer 

Engr 


( F rame 
Words) 


w 


Small Probe 


Store 


2W 
Sync 
+ ID 


30W 

Accelerometer Data 


(Frame 

Words) 


Descent 


2W 

9W 

5W 

4W 

3W 

3W 

2W 

2W 

6W 

9W 

Sync 
+ ID 

Nep j 

Accel 

Magn 

Temp 

Press 

Osc 

Play 

Back 

Engr 

Spares 


(F rame 
Words) 







TABLE 3-12. LARGE PROBE SAMPLING RATES 





BPS Above 20 km 

Parameter 

Resolution 

Required 

Derived SPS 
Requirement 

implemented 
( 10 bit words) 

7 and 10 Bit 
Words 

Accelerometer 

(axial) 

10 

1 

. 1. 6 

. 1. 6 

Accelerometer 

(lateral) 

10 

0. 05 

0. 5 

0. 5 

Turbulence 

7 

0. 143 

1. 6 

1. 1 

Transponder 

10 

0. 033 

1. 1 

1. 1 

Mas s 

spectrometer 

n- 

0. 0032 

48. 5 

48. 5 

Temperature 

10 

0. 18 

4. 3 

4. 3 

Pressure 

10 

0. 09 

2. 2 

2. 2 

Cloud particle 


0.44 

106. 2 

106. 2 

Solar flux 

10 

0. 07 

10. 8 

10. 8 

Planet flux 

10 

0. 07 

10. 8 

10. 8 

Aureole 


0. 65 

42. 0 

42. 0 

N ephelometer 

vl> 

T* 

0. 65 

13. 5 

13. 5 

Hydrometer 

7 

0. 18 

6. 5 

3. 78 

Playback 

D 

0. 5 

5.4 

5.4 

Engineering and 
science 
houseke eping 

7 


14. 0 

9. 8 

Synchronization 
and instrument 
detection 



7. 0 

7. 0 




276. 0 

268. 58 


^’Digital data 
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There are specific goals in format design which are useful in hard- 
ware minimization. First, the format should be short as possible. This, 
however, can lead to inefficient use of the data bandwidth. For example, if 
the data format were 32 words long the minimum signal sampling rate would 
be 1/32 times the bit rate. If the bit rate were 64 bps, 2 bps would be the 
minimum sampling rate that could be applied to a signal. If the bandwidth 
is used inefficiently, then for a given science instrument requirement a 
higher data rate would be required from the probe. This higher rate, of 
course, affects the rf link design. So a logical tradeoff exists between 
more logic for format design and more power for the rf subsystem. In 
actual fact (like the spacecraft), the rf power output capability is not con- 
tinuously variable, but exists at discrete levels due to addition or deletion 
of power amplifiers. So the design goal has been to develop formats that 
make most efficient use of a particular rf capability. 

Second, due to the nature of available logic components, it is desir- 
able to develop formats with lengths in powers of two. For example, for- 
mats of 32 or 64 words are desirable. The Thor/Delta and Atlas/Centaur 
baseline designs differ with respect to data formats and rates due to differ- 
ing descent characteristics and a payload update mentioned previously. The 
present Atlas / Centaur baseline design uses a 64 word format for both the 
minor frame and the subcommutator. 

Additionally, logic saving assumptions were made during establish- 
ment of the probe data handling subsystem requirements. These included 
utilization of a single ten bit word format and utilization of the data memory 
only during the high deceleration phase. 

Certain of the probe scientific instruments require ten bit (or 
0. 1 percent) analog-to-digital encoding accuracy. Other data, for example 
the probe and science instrument housekeeping data, require only 7 or 8 bit 
(0. 5 percent) accuracy. For purposes of design simplification, the differ- 
ing requirements were ignored and a simple 10 bit telemetry word was used 
across the board. Clearly there is some loss in data efficiency associated 
with this approach and some telemetry bits could be saved if seven bit words 
were transmitted as seven rather than 10 bits. Actually, the savings are 
small due to infrequent sampling of the seven bit words. 

The bit savings were analyzed for the large probe 276 bps descent 
data format. This format was chosen for analysis as it is the only format in 
which the science data requirement closely approaches the data transmission 
capability of the rf link. 

Three science instruments, all science housekeeping, and all engi- 
neering data channels (as shown in Table 3-12) could be reduced from 10 to 
7 bit words. If this were done, an additional 2. 69 percent data bandwidth 
would be available for expansion. This is equivalent to approximately 
7. 42 bps or 13. 8 words in the 512 word major frame- 
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Increased complexity would be required in the probe data system in 
order to sample and transmit both 7 and 10 bit words. The cost impact of 
such a change, however, would not be excessive (less than $100K), The 
same analog-to-digital converter would be utilized with only the 7 MSBs 
utilized for 7 bit words. Changes would be made to the formatter to tag each 
word for 7 or 10 bit transmission. 

It was, therefore, concluded that the cost and weight expenditures to 
implement both 7 and 10 bit word compatibility were not worth this small 
savings in data bandwidth. 

The probe data storage is used only for storing data during the high 
deceleration phase of entry. At this phase data rates are relatively high 
and rf communications are blacked-out, thereby requiring storage. An 
additional use of data storage would be as a data buffer. The buffer would 
store data during high instrument activity periods and playback at low 
activity periods. This use is attractive from the standpoint that data accu- 
mulation is desired at equal densities at all altitudes. Since the descent 
velocity is monotonically decreasing from entry through parachute release 
and again through landing, data could be stored during high descent rates 
and played back during slower descent rates. 

The data buffer concept was ruled out early in the study phase 

due to: 


1) Increased circuit complexity and associated costs 

2) Higher risk in data recovery due to the requirement to 
playback data on lower descent rates (!• e* , nearer the 
surface) 

3) Inability to reduce the size af the rf power amplifier and 
still meet the science data requirements 
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4. SUBSYSTEM TRADE STUDIES 


In the search for optimum design configurations and suitable hardware 
for the command and data handling subsystems, a number of major tradeoff 
studies were performed. These trade studies were concerned with both the 
probe bus and orbiter spacecraft, and also with the large and small probes. 
Although each of the studies were directed toward specific design objectives 
and employed particular criteria for their evaluation, they were generally 
intended to establish optimum designs that would both meet the following 
fundamental design objectives while still meeting the specified subsystem 
requirements: 

1) Minimize the development risk and provide a low cost 
implementation through maximum use of existing, available 
space hardware and by maintaining a maximum degree of com- 
monality (both units and circuits) between both the probe bus 
and orbiter spacecraft and the probes. 

2) Maximize equipment reliability through use of reliable com- 
ponents and by design simplification. 

3) Achieve minimum mass, power, and volume. 

4) Where possible, maintain design flexibility to accommodate 
changes in subsystem and science payload requirements as 
development progresses. 

The major aspects of each of these studies are discussed in this section as 
noted below. 

Command subsystem studies are presented in subsection 4. 1; they 

include; 

1) Command interface method s- 

2) Prevention of spacecraft inadvertent-irreversible command 
execution. 

3) Spacecraft command storage p,nalysis. 


4-1 



4) Probe cruise timer. 

5) Receiver reverse unit. 

Data handling subsystem studies are described in subsection 4.2 and 

include: 

1) Telemetry data recovery analysis. 

2) Data handling interface methods. 

3) Orbiter data storage analysis. 

4) Probe data storage hardware. 

5) Probe stored data playback techniques. 

6) Probe multiple data formats. 

7) Probe multiple data rates. 

A survey of available subsystem hardware is discussed in sub- 
section 4. 3. This subsection presents the results of a search to Locate 
appropriate command and telemetry data handling subsystem hardware that 
has already been developed for previous space programs. The survey 
included prior developments by both Hughes and by other space equipment 
manufacturers. 

Subsection 4.4 contains a summary of a tradeoff made between 
alternate pyrotechnic configurations to determine the best designs for the 
orbiter, probe bus, and probes. The analysis was based on initiator (bridge 
wire and hot wire) characteristics, reliable power switching methods, and 
power source characteristics. Selection was made of configurations which 
are highly reliable, low in cost, and. that meet system requirements. 

Finally, subsection 4. 5 presents the results and conclusions of a 
study that investigated the use of a programmable on-board data processor 
for performing major portions of the spacecraft command and data handling 
functions. A design that employs a small general purpose computer, on a 
time-shared basis, is described and compared with alternate designs. Major 
topics discussed in this section are: 

1) Centralized command and telemetry data handling subsystem 

2) Computer hardware survey 

The midterm Thor/Deltaperformance requirements were generally uti- 
lized as the parameters for these trade studies. For the sake of completeness, 
studies that have been performed since the midterm review, have been 
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included. In some cases these newer studies rely upon and include current 
Atlas /Centaur requirements. Where this is true, the study includes a 
statement indicating that it is based upon current Atlas /Centaur data. 

General effects to the trade studies of the current Atlas / Centaur 
mission are described in Section 6.2. 


4. 1 COMMAND SUBSYSTEM STUDIES 

Various aspects of the command subsystem were studied in order to 
establish optimum design techniques and methods of implementation. The 
studies emphasized utilization of existing design techniques and available 
space hardware so as to minimize development risk and implementation 
costs. Additional tradeoff objectives were to provide adequate safety mar- 
gins and to achieve minimum mass, power, and volume. 

The specific objectives, results, and conclusions of these studies 
are summarized below. 

1) Command Interface Methods. A study was performed to define 

a command interface that would satisfy all science and engineer- 
ing requirements. After considering various design techniques , 
the method of command interface that was selected is the same 
as that used on the OSO-I program. Since the command interface 
for OSO was developed specifically for use on a scientific space- 
craft, it is particularly well suited for use on Pioneer Venus. 

In addition to meeting all of the functional requirements, it meets 
all of the previously stated design objectives. 

2) Prevention of Spacecraft Inadvertent-Irreversible Command 
Execution. A survey was conducted to find acceptable means 
for preventing the inadvertent, execution of irreversible com- 
mands. Six basic techniques were investigated. They included 
techniques employed in previous space missions such as 
Surveyor, Pioneer F-G, OSO, and others. The use of interlocked 
commands was selected as the preferable method for Pioneer 
Venus. This method uses two independent, contiguous commands 
employing two independent Hamming code words. Since each 
Hamming code word is double-error detecting, an interlocked 
command cannot be inadvertently executed unless it contains five 
or more errors. Also, since this method was used on earlier 
Pioneer missions, it minimizes changes and impact on ground 
processing hardware and software. 

3) Spacecraft Command Storage Analysis. Requirements for 
command storage on both spacecraft are primarily derived from 
the need to automatically reorient the spacecraft and to deploy 
booms as soon as possible after spacecraft separation from the 
launch vehicle and, for the orbiter, to execute the periapsis 
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science instrument sequence- A study was performed to select 
an appropriate storage media for storing up to 64 commands on 
the probe bus and orbiter spacecraft. Both random access 
memories and shift registers of various semiconductor tech- 
nologies were considered. The study concluded that use of a 
long MOS shift register was preferred, since a sequence of time 
delayed commands is sufficient to implement the command 
storage requirements. This method was selected primarily 
because it minimizes the amount of hardware required for 
implementation. 

4) Probe Cruise Timer . Another tradeoff was performed between 
alternate designs of the probes’ cruise timer in order to deter- 
mine an approach which would consume minimum power during 
the cruise period, meet the timer accuracy requirement, and 
provide minimum technical risk- Two alternatives to the 
original design were considered. The selected approach uses 
the original oscillator /timer , but employs a switching regulator 
to provide more efficient voltage regulation than the series 
regulator proposed for the original design. This results in a 
reduction of total cruise power from 60 to 30 mW. 

5) Receiver Reverse Unit. Alternate designs of the spacecraft 
receiver reverse unit were analyzed to determine the best 
method to control the omniantenna/receiver combination to 
assure acquisition of an operating receiver/demodulator when 
only one omniantenna has earth visibility. The selected unit is 
a simple two state device. 

Each of these studies is described in more detail in the following 
sections. 

Command Interface Methods 

The purpose of this study was to define an optimum command inter- 
facing method for controlling of science instruments and engineering equip- 
ment on the four Pioneer Venus space vehicles. The particular interface 
to be investigated was that between the command subsystems and the users. 
A user is defined as a receiver of any command; the receiver may be a 
science instrument or another engineering subsystem. The study was to 
include any commands that are to be transmitted from the command subsys- 
tem to a user, either in real time or from a stored command memory. 

The investigation was guided by a procedural approach, which was 
designed to meet the fundamental objectives previously stated (i.e., use 
available space hardware to minimize cost and development risk; achieve 
maximum reliability and hardware commonality; minimize mass, power, 
and volume; where possible, maintain flexibility to accommodate changes). 
The procedure for conducting the study was: 

1) Establish guidelines that define optimum command interface 
features and characteristics for scientific type spacecraft; 
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the interfaces must be sufficiently flexible to accommodate a 
multiplicity of science instrument and equipment complements 
with maximum standardization. 

2) Survey and evaluate existing hardware designs; consider new 
designs only if appropriate existing hardware is not available. 

3) Select the most appropriate hardware design based upon the 
above objectives and guidelines. 

4) Define the specific characteristics of the selected design and 
establish their particular relationship with the Pioneer Venus 
applications. 

After the interface guidelines were established, a survey was 
conducted to solicit information on previously developed command subsystem 
hardware from known suppliers of space equipment. Details of this survey 
are reported in subsection 4. 3. Evaluation of existing equipment designs 
from six different companies resulted in selection of the command interface 
hardware designed for the OSO-I program. 

The OSO interface hardware is felt to be an optimum choice for all 
four space vehicles. After all the surveyed equipment was evaluated, it was 
found that most of the other equipment designs met portions of the above 
objectives and guidelines to varying degrees. However, the OSO hardware 
was the only interface equipment located that meets all of them without modi- 
fication. This hardware is a very current design and uses modern LSI 
technology to reduce mass and improve reliability. It was developed speci- 
fically for use on scientific spacecraft. It is particularly well suited for 
Pioneer Venus, since the interface requirements for these scientific space- 
craft are very similar to those of OSO-I. 

A summary of some of the more pertinent aspects of this study is 
given below. Detailed results of the study may be found in Reference 4-1, 

Interface Guidelines 


Guidelines that define optimum command interface features and 
characteristics are summarized below. Whereas these guidelines were 
specifically established for this study, they have evolved from Hughes 
extensive experience in spacecraft design (e. g. , Surveyor, ATS, OSO, plus 
several military and communications satellites) and from the experience of 
other agencies. 

1) Design modularization should be employed to achieve configura- 
tion flexibility. Modularization will allow tailoring the number 
of hardware modules to accommodate a higher or lower number 
of command interfaces as dictated by the specific application. 
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2) The command interface should be capable of providing two 
basic types of digital commands to users. The first is a dis- 
crete, pulse' type command to initiate modes and events; the 
second is a serial data or magnitude type command to transfer 
digital data and quantitative information to users. 

3) A logical 1 should be associated with a source of energy (a 
positive voltage source supplying current, or a negative voltage 
sink absorbing current). 

4) A logical 0 should be an inert state (such as zero volts with no 
current flow) such that the control wire could be shorted to 
ground or open circuited without creating a false signal. An 
inert state also permits a considerable spacecraft power saving, 
since a unit can be completely powered off when it is inactive. 

5) Commands or control signals from redundant sources should be 
able to be "OR^ed'’ together, and a single component failure in 
one source should not prevent proper operation of the redundant 
source. This is achieved by providing a diode '^OR^’ing capabil- 
ity in the command interface receiving buffer. This feature also 
prevents an open wire, an open connector pin, or a short to 
ground in the harness from disabling the redundant command 
source or path. The inactive unit should be powered off in a 
standby redundant mode of operation. This is possible with the 
logic levels defined above. 

6) A command or control line should have a fanout of at least two 
(when using a standard input buffer), enabling a single output to 
control two functions simultaneously. 

7) System noise immunity must be achieved. A good way to achieve 
this is by providing threshold detection, which has hysteresis 
and a large signal/threshold ratio, plus filtering (e. g. , a 
relatively large signal voltage swing around the hysteresis 
threshold Levels plus a controlled integration of current over 
time). 

8) A command should be a logic signal rather than a power signal 
to minimize EMI noise generation. 

OSO Interface Design Description 

The command output modules of the OSO command subsystem meet 
all of the command interface guidelines described above; in OSO terminology, 
these modules are called remote decoders. Each of these modules provides 
the interface capability for 64 pulse commands and 4 serial data (or serial 
magnitude) commands. 
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Tables 4-1 and 4-2 summarize the basic features and output 
characteristics of pulse and serial magnitude commands, respectively. 

Each pulse command is transmitted to the user on a single line, while each 
magnitude command is transmitted via three interface lines; one line is for 
transmission of serial NRZ data, one is for the associated read clock signal, 
and the third line is for the associated read envelope signal that defines the 
time period during which valid data is to be recognized. 

Interface Circuit Descriptions 

For user convenience, two types of integrated circuits have been 
developed by Hughes to alleviate any potential interfacing difficulties. They 
are compatible with the OSO command hardware, and were developed to 
permit standardization of signal interfaces between the command subsystem 
and the users. Furthermore, they can accommodate buffering requirements 
for essentially any type of low frequency digital signals. It is recommended 
that these circuits be employed in the users equipment to insure interface 
compatibility with the command subsystem. Otherwise, the interface cir- 
cuits in the users equipment should have equivalent characteristics. These 
integrated circuits are: 

1) Standard Input Buffer . This device, Hughes part number 908974, 
is a dual line receiver that is used to receive command signals, 

2) Standard Output Buffer . This device, Hughes p3«rt number 
908973, is a quadruple line driver. It is recommended that this 
circuit, or its equivalent, be employed by the user to provide 


TABLE 4-1. PULSE COMMAND CHARACTERISTICS 


Parameters 

Characteristics 

Logic 1 (execute) 

>12 V while supplying 4 mA (open 
circuit voltage = +15 ±2 V) 

Short circuit protection 

Current limiting is provided for pro- 
tection against shorts to ground 

Fanout capability 

Two (with standard buffers) 

Logic 0 (quiescent) 

0 V (signal ground) through a source 
impedance of 5.3 ±2.9 kU 

Pulse width 

50 ms nominal 

Voltage rise time 
(10 to 90 percent) 

2.5 jjLsec maximum (with load of 700 pF 
capacitance in parallel with 30 kU 
resistor to ground) 

Voltage fall time 
(90 to 10 percent) 

15 jjLsec maximum (with load of 700 pF 
capacitance in parallel with 30 k^2 
resistor to ground) 
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TABLE 4-2. SERIAL MAGNITUDE COMMAND CHARACTERISTICS 



Control Line Characteristics 

Parameter 

NRZ Data 

Read Clock'^ 

Read 

Envelope''' 

Logic 1 

>12 V while supplying 4 mA 
(open circuit voltage = +15 
±2 V) 

Same 

Same 

Short circuit 
protection 

Current limiting is provided 
for protection against shorts 
to ground 

Same 

Same 

Fanout 

capability 

Two (with standard input 
buffer Hughes Part No. 
908974 

Same 

Same 

LiOgic 0 

0 V (signal ground) through 
5.3 ±2.9 kfl source 
impedance 

Same 

Same 

Voltage rise 
time 

Less than 2.5 psec 

Same 

Same 

Voltage fall 
time 

Less than 14 psec 

Same 

Same 

Load for rise 
and fall times 

700 pF in parallel with a 
standard input buffer (or 
30 kn). This corresponds 
to a total line length <14 ft 

Same 

Same 

Word length 

10 bits 



Bit rate 

16 kbps ± 1 percent 

Same 

— 

Envelope 
pulse width 



0.680 ± 
(TBD) ms 


^Characteristics of the read clock and read envelope lines are the same 
as for the NRZ data line, except as noted. 
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any necessary event type signals; occasionally, these types 
of signals are used to notify the command subsystem of an 
occurr ence'that requires command action. 

A major feature of these integrated circuits is their exceptionally 
good immunity to noise. Since the driver and receiver circuits have been 
designed to be compatible, they eliminate many interface problems related 
to electrical ground references; e. g. , connection transitions between signal 
ground, power ground, etc. associated with the interfacing equipments. 

They also insure proper matching of electrical interface characteristics, 
including cabling capacitance. In addition, they provide simple and reliable 
methods for cross-strapping of redundant units. 

The 908973 and 908974 interfacing circuits may be used in a variety 
of modes, depending upon the specific interfacing requirements; detailed 
descriptions of their usage for various interfacing applications may be found 
in Refer ences 4- 1 and 4-2. 

Spacecraft Command Applications 

The command subsystems of the probe bus and orbiter spacecraft 
provide the means for commanding science instruments, other subsystems, 
and pyrotechnic devices. Commands can be transmitted either in real time, 
via the command uplink, or from the stored command memory. Both pulse 
and serial magnitude types of commands are utilized. Spacecraft commands 
are distributed by redundant sets of remote decoder modules. Because of 
this redundancy, any single failure in a remote decoder will not be detri- 
mental to the user's operation. Each decoder is capable of distributing 
64 discrete pulse commands and 4 serial magnitude commands. The pulse 
commands are low power signals with a nominal logical 1 time duration of 
50 ms. Each serial data command channel consists of three low power sig- 
nals, whose logical 1 and logical 0 states are time dependent such that the 
intelligence (magnitude data) is determined by the relative timing of the 1 
and 0 states. The time duration for the transfer of one serial data magnitude 
command is nominally 1 ms. Command subsystem/user interface signals 
from redundant decoders are "OR'ed" together at the user's end in order to 
provide a redundant command interface. 

Probe Command Applications 

The command sections of the probe command and data handling sub- 
systems receive pulse and magnitude commands from the probe bus prior to 
separation of the two vehicles. These commands are used to initiate and 
terminate preseparation tests, to provide 20 bits of time information to the 
probe's cruise timer, and to start the timer. 

After separation of the probes from the probe bus, the timer initiates 
preentry events with an accuracy of ±20 sec following a nominal 20 day cruise 
period. After the separation, all pulse commands generated by the command 
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section result from fixed stored commands and from event occurrences 
signaled by probe subsystems and science instruments* Only pulse type 
commands are provided by the probe command section; no magnitude type 
commands are required* The pulse command characteristics for the probes 
are the same as for the spacecraft* 

Each probe must process a small number of event signals* These 
signals originate as outputs from various sensors and/or science instru- 
ments. The electrical output characteristics of these signals shall be 
compatible with the input requirements of the standard input buffer interface 
circuit (Hughes part number 908974); these required output characteristics 
are shown in Table 4-3. To insure this compatibility, it is recommended 
that the standard output buffer (Hughes part number 908973) be used. 

Prevention of Spacecraft Inadvertent-Irreversible Command Execution 

Summary 

A major concern with any spacecraft mission is protecting against 
the possibility of any event that may jeopardize the total mission and that 
cannot be corrected from the ground. This could be the case for certain 
critical functions that may erroneously be executed and that are irreversible; 
X. e. , where no corrective action can be taken to save the mission. An 
inadvertent command to fire a squib driver is an example. 


TABLE 4-3. PROBE EVENT SIGNAL REQUIREMENTS 


Parameter 

Characteristics 

Logic 1 (execute) 

+ 12 to +17 V while supplying 4 mA 

Short circuit protection 

Current limiting to 50 mA. for 
protection against shorts to ground 

Fanout capability 

Two (with standard buffers) 

Logic 0 (quiescent) 

0 V (signal ground) through a source 
impedance of <30 kS7 

Voltage rise time 
(10 to 90 percent) 

25 |asec maximum (with load of 700 pF 
capacitance in parallel with 30 kf2 
resistor to ground) 

Voltage fall time 
(90 to 10 percent) 

100 [jLsec maximum (with load of 
700 pF capacitance in parallel with 
30 kn resistor to ground) 


4-10 




Because of this concern, a study was conducted to select a technique 
for preventing inadventent irreversible commands from being executed by 
the probe bus/orbiter command subsystem. The first part of the study con- 
sisted of a survey of prevention techniques that have been used, or suggested 
for use, in previous space missions. These techniques include various error 
detecting codes, address check, repetition of the data, interlocked commands, 
and command verification via telemetry. 

The second part of the study task consisted of a tradeoff to select the 
technique best suited to the Pioneer Venus requirements. Interlocked com- 
mands, used by ARC on earlier Pioneer missions, were selected as best for 
Pioneer Venus. Interlocked commands, to be issued only from a command 
memory for mission critical functions, were selected for the following 
reasons; 


1) Flexibility in handling both irreversible and noncritical commands 
with a single format 

2) Compatibility with existing Pioneer ground equipment 

3) Protection against human error in initiating an irreversible 
command, since two independent actions are required for 
initiation 

Command verification via telemetry readout of magnitude registers 
was recommended as a backup technique for verifying critical magnitude 
commands. 

Discussion. 


The study established that the maximum number of errors that must 
be detectable is approximately four. Four was chosen for Pioneer Venus, 
since it guarantees very low probability of accepting an invalid command, 
and because it is consistent with previous spacecraft command subsystem 
designs. 

The survey of techniques included those used by Pioneer F and G, 
Surveyor, OSO, and' other space missions. The techniques investigated can 
be classified roughly as follows: 

1) Interlocked commands . Interlocked commands are defined as 
a sequence consisting of two independent commands, each 
command containing a block code that is double error detect- 
ing. An interlocked command cannot be inadvertently executed 
unless it contains five or more errors. The interlocked com- 
mand concept is easily adapted to noncritical commands by 
simply omitting one of the two independent commands; no change 
in the command format is necessary. This is the preferred 
method. 
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2) Block codes ^ A block code is a group of bits, added onto the 
command word, that contain parity information for detecting 
multiple errors- Codes investigated were Hamming and cyclic 
codes, including BCH- A single block code word is adequate 
for noncritical commands- 

3) Transmission of the command and its complement- This 
method is very inefficient, in terms of transmission rate, and 
does not guarantee that all double errors will be detected. This 
method was discarded for these reasons. 

4) Command format check- A command format check consists of 
verifying that the received command contains an error-free 
address sequence. This is an effective technique for detecting 
burst errors, but is inadequate in a link where errors tend to 
be independent- This technique was not selected since it does 
not provide enough error detecting capability. 

5) Ground verification before execution- This method requires an 
additional command to initiate execution after the command has 
been verified- In effect, two transmissions are required to 
execute a single real time command- Because of the built-in 
time delay, this technique was eliminated from consideration 
for irreversible commands. 

The detailed rationale for selection of the interlocked command 
method may be found in Reference 4-3- 

Spacecraft Command Storage Analysis 

Requirements Analysis 

The requirement for command storage on both spacecraft is derived 
from the need to automatically reorient the spacecraft and deploy booms as 
soon as possible after spacecraft separation from the launch vehicle. Addi- 
tionally, orbiter events of orbit insertion during occuitation and occulted 
periapsis operations require stored command Sequencing- 

Command sequences for control of events following separation from 
the launch vehicle will be entered into the command memory and their cor- 
rectness verified prior to launch- Upon separation command memory 
operation will be begun by sensing the separation switch closure and subse- 
quently enabling the spacecraft stored command processor- All other stored 
sequences will be initiated by the first edge of the first 30 min dock interval 
pulse which follows reception of a real time command to execute memory 
operation. By this means, the command to initiate the stored sequence can 
be sent more than once to increase the probability of its successful execu- 
tion, and the time criticality of its transmission is eliminated- 
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Memory words consist of either time information, command 
information, or zeros. Upon initiation,the stored command processor will 
increment the memory, which is in the form of a Z048 bit shift register, 
until it encounters a non^-zero bit that indicates time or command information. 
If the first word is a command word the indicated command will be immedi- 
ately executed as will subsequent command words until a time word is 
encountered. The time information will be entered into the stored command 
processor time counter which will then be decremented by the spacecraft 
master clock until it underflows. Upon sensing the underflow condition the 
stored command processor will interrogate the memory and execute com- 
mands until it encounters the next time word. The process continues and 
the memory end-around- shifts until a command to halt memory execution 
is encountered either in the real time command link or in the command 
memory. The delta time delay technique indicated simplifies the determina- 
tion of command sequences on the ground and reduces time register size 
requirements on the spacecraft. The end-around- shift feature allows cyclic 
or noncyclic sequences to be executed by either omitting or including in the 
sequence a command to halt memory operation. 

Command word size is determined by the magnitude command storage 
requirement of 16 bits plus 2 bits to indicate time /magnitude/pulse command 
word type plus 5 bits for addressing for a total of 23 bits minimum. Time 
information requires the 2 bit word identifier plus 16 bits of time information. 
Pulse command information requires the 2 bit word identifier plus a 9 bit 
address. A 24 bit word is selected since a smaller word would require trans- 
mitting more than one command to load a magnitude command word thereby 
unduly increasing the time required to load the command memory. 

Stored sequence requirements at launch, orbit insertion, and during 
on orbit occultations determine command memory size in words. Table 4-4 
presents sequences for these events. Using a 2^ size shift register it is 
seen that a 1024 bit (42 word) register is sufficient. A 2048 bit register is 
selected to accommodate growth. 

Timing of the radar altimeter rf pulse relative to the sun pulse 
depends on spacecraft- Venus geometry as does the altimeter antenna eleva- 
tion angle which is slewed using a phased array approach. The desire is to 
transmit the rf pulse when the antenna is pointed along the local vertical. It 
was found that a pulse timing and antenna pointing algorithm exists and 
requires approximately six constants to be entered before each periapsis 
pass. It was assumed that the algorithm would be implemented within the 
experiment. Therefore, the periapsis occultation sequence in Table 4-4 
Indicates the need to extract six constants, in the form of magnitude com- 
mands, from the command memory. 

Hardware Implementation Analysis 

A study was performed to determine the most applicable method for 
implementation of the probe bus and orbiter command memories. Tech- 
nologies and techniques were both studied. The results of the study led to 
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TABLE 4-4. BUS COMMAND MEMORY SEQUENCES 





Memory Words 

Subsequence 

Time 

Com mand 

Time 

Command 

Post separation 

Sep +0 

Separation switch initiates 
memory operation 

- 

- 


Sep +10 sec 

JCE-ON 

1 

1 



Lioad despin data 


2 



Execute despin 


2 


Sep +50 sec 

Terminate despin 

1 

1 



PCU-ON 


1 



Deploy booms 


2 



PCU-OFF 


1 


Sep +23 min 

Eoad reorientation data 

1 

3 . 



Execute reorientation 


2 


Sep +26 min , 
20 sec 

Terminate reorientation 

1 

1 



Total words; 

4 

16 

Orbit insertion 

I -45 min 

Initiate memory operation by 
ground command 

- 

- 


I -40 min 

Test command 

1 

1 


1-25 min 

Test command 

1 

1 


1-200 sec 

Execute Liquid thrusting 

1 

2 

i 

I +0 

Terminate liquid thrusting 

1 

1 



PCU-ON 


I 



Ignite OIM 


2 



PCU-OFF 


1 


I +lh 

Lioad reorientation 

1 

3 



Execute reorientation 


2 . 



Terminate reorientation 

1 

1 


I +lh, 20 min 

LfOad MDA despin data 

1 

2 


■ i 

Despin MDA 


1 


1 

Total words: 

7 * 

18 

PeriapsLs occultatLon 

P - 15 min 

Initiate memory operation by 
ground command 

- 

- 


P - 8, 4 min 

1000 km science ON 

1 

2 


P -4. 2 min 

Altimeter rate change 

1 

1 


P -0 

Change altimeter algorithm 

1 

6 


P +4, 2 min 

Altimeter rate change 

1 

1 


P +8. 4 min 

1000 km science OFF 

1 

2 


P + 1 1 min 

Fire jets for period trim 

1 

2 


P +11.2 min 

Terminate jet fire 

1 

1 


i 

Total words; 

7 

15 
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the selection of a static MOS shift register for command storage. This 
selection was based on its simplicity of configuration and the fact that only 
64 delay functions are required to be implemented. 

The methods reviewed were shift registers and random access 
memories (RAM). The hardware reviewed consisted of core RAM, MOS 
shift registers, and MOS RAM. The advantages and disadvantages of each 
method and hardware type are briefly summarized below. 

Random Access Memories . The advantages of using a RAM are 
as follows; — 

1) Any memory location can be loaded independently of other 
locations. This feature allows memory corrections to be 
made in a minimum time. 

Z) Faulty sections of the memory may be deleted by a jump 
command. 

The disadvantages of using a RAM for a command memory are: 

1) Extra logic is required for keeping track of word locations; 
this hardware basically consists of a sequencer and address 
register. 

Z) Complexity of the RAM itself is usually high because of mul- 
tiple drivers and sense amplifiers. 

Some characteristics of magnetic and semiconductor RAM memories 
are as follows: 

1) Magnetic memories are nonvolatile and can be power strobed to 
keep power to a minimum. They are usually large and, unless 
the required memory is greater than 2x10^ bits, they are 
usually not preferred unless power is the prime consideration. 

2) MOS semiconductor RAMs are the preferrable semiconductor 
technology for this application. The reasons for preferring 
MOS devices are that they represent the highest bit density per 
package and the lowest power per bit as compared with other 
existing semiconductor technologies. The primary advantage 
of MOS RAMs over magnetic RAMs is that they can be easily 
configured to a particular bits/word combination. The primary 
disadvantage is that they are volatile and must be powered 
continuous ly. 
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Shift Registers. The advantages of using a shift register for a 
command memory are as follows: 

1) A minimum of control hardware is required. 

2) Memory length can be added easily. 

3) Recycling is extremely simple. 

The disadvantages of using a shift register are; 

1) An entire stored command sequence must be loaded with no 
errors; e. g. , if the bit error rate is 10"^ and sixty-four 
36-bit commands must be loaded, then the probability of 
loading correctly is 97.5 percent. 

2) If one bit in the memory fails, the entire memory is lost. 

3) Only delay functions can be implemented. 

4) They are volatile and must be powered continuously. 

Probe Cruise Timer 

A tradeoff was performed between alternate designs of the probes' 
cruise timer in order to determine an approach which would consume mini- 
mum power during the cruise period, meet the timer accuracy requirement, 
and provide minimum technical risk. The primary goal was that reduction 
of power consumption ultimately allows a reduction in the mass of the probe 
batteries. Three different designs are considered and compared. They 
employ various combinations of frequency sources and voltage regulation 
methods and range from 15 to 60 mW of power. The selected approach uses 
a 1 MHz crystal oscillator in conjunction with a switching regulator and con- 
sumes 30 mW. 

Background 

This study was undertaken subsequent to the midterm review to 
determine alternate means of reducing power consumption in the probes' 
cruise timer and the relative cost and complexity of those alternatives. The 
overall accuracy requirement for the timer is ±20 sec in 20 days, including 
oscillator stability plus timer resolution. Assuming ±2 sec resolution for 
the timer, oscillator stability and aging effects must be kept to approximately 
1 X 10-5 (17. 3 sec in 20 days). 

The initial design employs a 1 MHz oscillator, complementary MOS 
(CMOS) logic for the countdown chain and timer, and a series regulator to 
provide a +5 V logic supply from the 18 V probe battery source. This design 
requires 60 mW of power during the 20 to 23 day cruise period prior to entry 
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into the Venus atmosphere* Most of the power consumed is in the timer ^s 
oscillator, the initial few stages of countdown, and in regulation inefficiency; 
the latter is due to the fact that the timer operates directly from the probe 
battery which must be regulated down from approximately 18 to 5 V for use 
by the timer. 

Sixty mW of power represents Z8. 8 W-hr of energy over a ZO-day 
cruise period. At the present battery energy density, this is equivalent to 
approximately 0.45 kg (1 lb) of battery weight; a 30 mW reduction. in timer 
power would reduce the total weight of each probe by 0. ZZ kg (0. 5 lb). 

Cruise Timer Design Alternatives 

The study was concentrated upon the two primary sources of power 
consumption: the oscillator and the voltage regulator. Low frequency timing 
references were investigated, as low frequency oscillators in general require 
less power than higher frequency circuits. Alternate methods of regulation 
were considered, as was operation directly from, the probe battery voltage. 

A summary of the timing references considered, with relevant design 
implications, is given in Table 4-5. The ’’G-T cut” quartz crystal is 
generally undesirable for space use due to its physical size and questionable 
ability to withstand the mechanical stresses of a normal spacecraft launch. 
The bimetallic tuning fork, in addition to being bulky, cannot provide the 
accuracy required of the cruise timer. The quartz tuning fork reference 
will not provide the 1 X 10-5 stability over the required temperature range; 
however, the stability can be controlled by controlling the temperature of 
the crystal or by temperature compensating the oscillator circuit, thereby 
achieving the desired accuracy. The initial design uses an ”A-T cut” quartz 
crystal and has the advantage that it inherently meets the required accuracy, 
it uses a space proven design, and it uses presently qualified parts. The 
single disadvantage is the higher power dissipation. 

The greater part of the power dissipation in the initial design (about 
75 percent) is attributable to series regulation for conversion of the 18 V 
probe battery supply to the 5 V used by the timer. The use of a switching 
regulator, in lieu of the inefficient series type, can reduce the total power 
required by at least 50 percent (to 30 mW) at the cost of a slight increase 
in parts. The switching regulator would not be advantageous in a design 
using a low frequency crystal, since the current drain for this approach is 
quite small (less than 1 mA) and the efficiency of the switching regulator at 
extremely small loads is not significantly different from that of the series 
regulator. 

Results 


The results of the study indicate that two alternate approaches are 
worth consideration. The first uses the initial oscillator design but with a 
switching regulator to improve regulation efficiency; the second employs 
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TABLE 4-5. CRUISE TIMER TIMING REFERENCES 


Timing Reference 

Manufacturer 

Space 

Qualified 

F requency 

Timer Stability 
+ Aging(l) 

Timer 
Power , 
mW 

"A-T cut" quartz crystal 

Bliley 

Yes 

1 MHz 

1 X 10'^ 

30 

"G-T cut" quartz crystal 

Bliley 

No 

250 kHz 

1 X 10"^ 

20 

Quartz tuning fork 

Statek 

No 

32 kHz 

5 X 10"^ ' 

15 

Bimetallic tuning fork 

Bulova 

No 

16 kHz 

1 X 10"^ 

15 <5> 


(1) Stability specified as-^over temperature range from 0 to 40 "C; aging specified as — for 
1 year. 

(2) Includes switching regulator inefficiency at 18. 2 V bus. 

(3) Includes series regulator inefficiency at 18. 2 V bus. 




a low frequency quartz tuning fork which is much lower in power than the 
initial design and retains the series regulator of the initial approach. 

The first approach is preferred in spite of the fact that it consumes 
30 mW compared to 15 mW for the latter. This is because the initial oscil- 
lator is a proven design and requires no new part qualifications. The latter 
approach uses a quartz tuning fork timing reference that inherently is not 
as stable as the initial design. The cost of designing around the stability 
(e. g. , by temperature control) is enough so as to reduce the attractiveness 
of this approach. In addition, the device is not presently qualified for use 
in space and the manufacturer has not supplied parts to Hughes for space 
qualification in the past. 

Receiver Reverse Unit 

When only one omniantenna has earth visibility, acquisition of an 
operating receiver /demodulator is vital; otherwise this wilt result in the 
inability to command the spacecraft. The function of the receiver reverse 
unit (RRU) is to control the omniantenna/receiver combination, either auto- 
matically or by command. 

Two RRU functional designs have been originated and analyzed. The 
first is essentially a two state device which issues standard commands to 
the transfer switch between the omniantennas and the receivers altering of 
antenna /receiver configuration. Switching would not be necessary if both 
omniantennas could be permanently connected to both receivers, but such a 
permanent connection results in fringes in the resulting omniantenna pattern. 
On the orbiter, command reception is not possible at extreme ranges using 
the omniantennas and the DSN 26 meter net so a switch was incorporated to 
allow use of the high gain mechanically despun antenna (MDA). 

Factors considered in determining the RRU switching algorithm are 
the following: 

1) The switch controls downlink energy to the antenna subsystem as 
well as uplink energy. Thus,- switching of the SPDT switch 
when unwarranted can cause unnecessary loss of downlink. 

2) Both switches are electromechanical and thus have limited 
cycle lifetimes. 

3) Periods of time will exist during which no uplink energy will be 
received due to ground station outages, occultations , addressing 
of the alternate Pioneer Venus spacecraft, or ground station 
utilization conflicts with other projects. 

4) Spacecraft attitude can be such that only one omni has earth 
visibility. 
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5) Single unit failures shall not be capable of disabling the ability 
to command the spacecraft. 

6) Receivers and spacecraft are frequency addressable. 

The following algorithm results from considering spacecraft safety 
as the prime algorithm selection criterion. 

1) Upon sensing that no valid real time command has been received 
within the preceding interval, or that no command has been 
issued from the stored command processor to force the state of 
the antenna/receiver transfer switch within the preceding 
TBD hours, the RRU shall switch the SPOT switch to replace 
the MDA with the forward omni. This action guarantees that 
MDA pointing cannot effect command reception. At the same 
time the RRU shall switch the antenna/r eceiver transfer switch, 
as the new combination is more likely to be operable since it is 
known that the alternate configuration is likely to have a failure. 

Z) The RRU timer shall operate continuously. It shall be reset 
whenever a real time command is received, or whenever a 
command is received from the stored command processor to 
set the state of the antenna/receiver transfer switch either to 
its existing state or to a new state. Issuance of this latter type 
of command, therefore, effectively overrides RRU switching for 
the reset period. An override is necessary in order to minimize 
the switching in the rf subsystem during predictable periods when 
no uplink will be received by the spacecraft. Previously it was 
desired to override RRU operation by stopping the timer. 
Replacement of this override implementation eliminates a pos- 
sible failure mode in time clock control circuitry and reduces 
pulse command requirements by two. There is also no longer 
a means for indefinitely disabling the RRU. 

An alternate algorithm is to refrain from switching out the MDA 
until a certain number of hours after switching of the antenna/receiver transfer 
switch. This would minimize the possibility of losing the downlink when unwar- 
ranted (i. e. , when an anomaly other than antenna pointing causes los s of command 
Link). However, it is considered that antenna pointing is a more likely 
source of link interruption than receiver or demodulator unit failures. This 
algorithm is, therefore, discarded in favor of the preceding one. 

Use of the polynomial code validity indicator, rather than the receiver- 
in-lock indicator, as a stimulus for resetting the RRU timer, results 
in more failure immune RRU operation. This is most apparent when only 
one antenna has earth visibility. If the receiver connected to this antenna 
is intermittently in lock; if it is falsely indicating an in-lock condition; or if 
it is in lock and its associated demodulator has failed such that it cannot 
obtain bit synchronism; then no commands can be received, yet the RRU will 
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never alter configuration. Use of the polynomial code validity circumvents 
these problems- In addition, an interface between the RRU and the receivers 
is unnecessary. The failure mode of the polynomial code circuitry to falsely 
indicate valid command reception is unlikely, since the signal is in the form 
of pulses and most failures are of a dc nature. Should this failure occur, the 
alternate central decoder would be utilized for command decoding and the 
polynomial code check would be available from this source. 


For the probe bus spacecraft, the RRU implementation will be identi- 
cal. There will simply be no output to an SPDT antenna select switch since 
none exists. 

A previous RRU functional design has been discarded. For that 
scheme, the RRU was basically an eight state device which controlled con- 
nections between antennas and. receivers, receivers and demodulators/ 
central decoders. Such a technique had the advantages that receivers could 
receive on the same frequency and 100 percent cross- strapping was employed, 
giving the safest redundant system possible. The disadvantage, which led 
to replacement by the above RRU design, was the relatively complex imple- 
mentation. It is felt that the operational difficulties imposed by frequency 
addressable receivers are outweighed by the simplification realized in the 
above design. The only cross strapping lost was in the receiver /demodulator 
connection. 
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4. 2 DATA HANDLING SUBSYSTEM STUDIES 


Investigations were made and tradeoff studies performed on various 
aspects of data handling subsystem functions in the bus/orbiter spacecraft 
and the Large and small probes. The studies resulted in an optimum solution 
of system tradeoffs and in better definition of the data handling subsystem 
baselines. In some instances the hardware or design technique selected 
represents the best solution presently available and could change at a later 
date, based upon further definition of subsystem requirements or hardware 
developments . 

A summary of the studies performed is given below. The principal 
criteria used in performing the studies and the pertinent conclusions and 
results are included. 

1) Telemetry Data Recovery Analysis. An analysis was performed 
of the process of telemetry data recovery. Elements of the 
DSN which detect, recover, and decode telemetry data were 
examined. Characteristics of these elements were accounted 
for in order to assure data systems compatibility with the DSN 
and to maximize the amount of data return for both multiprobe 
and orbiter missions. 

2) Data Handling Interface Methods . A study was performed to 
define a data handling interface, for both spacecraft and probes, 
that is optimum in terms of reliability and flexibility and that 
also makes maximum use of existing designs in order to 
minimize cost and provide a firm baseline for accurate pricing. 
After considering various design techniques, the data handling 
interface method that was selected is the same as that used on 
the OSO-I program. Since the OSO design was developed spe- 
cifically for scientific data handling and accommodates a variety 
of signal interface types, it is particularly well suited for use 
on Pioneer Venus. 

3) Orbiter Data Storage Analysis . Overall data storage require- 
ments have been derived from data rates associated with 
different phases of the Pioneer Venus mission. A data storage 
size of 1,048,576 bits is attractive as it meets data storage 
requirements for the periapsis and apoapsis phases. Another 
tradeoff study was conducted on memory technologies for data 
storage use on the orbiter spacecraft. The major objectives 
were to determine applicability and availability for space use 
at minimum cost. It was determined that both magnetic core 
memory and semiconductor dynamic MOS memory are feasible 
for use on Pioneer Venus. The magnetic core memory was chosen 
because of its low cost, relatively low power, and the fact that 

it is a space proven technology and offers the minimum technical 
risk. . 
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4) Probe Data Storage Hardware ^ A tradeoff study was also 
performed for data storage use in the probes. A separate study 
was warranted because of the considerable difference in storage 
requirements between the orbiter and the probes (approximately 
393 kilobits for the orbiter compared to 4 kilobits for the large 
probe). The study determined that semiconductor memories 
should be used on the probes due to their small size, mass, and 
cost in applications requiring low storage capacity. A bipolar 
Z56 bit memory, which is presently being space qualified, is 
preferred for the probe design. However, large semiconductor 
memories, both bipolar and MOS, are becoming available and 
appear to be suitable for space use. One of these may become 
preferable at a later time, depending upon availability and 
qualifica|:ion costs. 

5) Probe Stored Data Playback Techniques . An additional study was 
conducted to determine whether the stored data in the probes 
should be played back in a single '’burst dump” of the memory 

or whether it should be interleaved with real time data in a 
single format. It was found that the burst dump technique did 
not allow a power reduction in the probes as originally thought, 
and, because of the added complexity of this technique, the 
approach of interleaved playback is preferred. 

6) Probe Multiple Data Formats . An investigation was made to 
determine the impact upon the probe data handling subsystem of 
providing two or more downlink data formats in order to 
accommodate different science sampling rates during probe 
descent. It was found that the cost to the probe design of provid- 
ing multiple data formats was minimal due to the fact that read 
only memory (ROM) elements are used to program the probe 
format. Depending upon the number of inputs and the sampling 
requirements of each, the cost may only entail provision of the 
additional command outputs necessary to change formats. It was 
concluded that the advantage to be gained by providing multiple 
formats, (i. e. , to meet science data return requirements with- 
out having to add increased rf power amplication) was worth the 
possible increase in complexity. 

7) Probe Multiple Data Rates . A study task was conducted to 
determine the impact upon the probes of providing two or more 
bit rates in the data handling subsystem, since the use of lower bit 
rates during the latter phases or probe descent allows a reduc- 
tion of power consumption in the communications subsystem. 

It was determined that there is minimal cost impact if the 
multiple bit rates are related by an integral binary ratio 
(e.g. , 2^:1 such as Z:l, 4:1, etc. ), or by certain nonbinary 
ratios (e-g., 2^:3 such as 1:3, 2:3, 4:3, 8:3, etc.). The small 
additional cost is due primarily to the circuitry required to 
change bit rates, including the additional command outputs 
necessary from the command subsystem. 
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FIGURE 4-1. COMPOSITE SS A AND DDA ACQUISITION AND IN-LOCK 
CONFIRMATION TIME FOR SEQUENTIAL DECODING OF 
CONVOLUTIONAL CODED DATA (CURRENT ATLAS/CENTAUR 
BASELINE) 




Each of these studies is described in more detail in the following 
sections. 

Telemetry Data Recovery Analysis 

Requirements for specialized hardware and software necessary to 
process the telemetry data to an uncoded PCM data stream have been 
examined. The spacecraft has been designed so that specialized equipment 
or software are not required. Equipment and routines presently in use on 
the Pioneer 10 and 11 programs are satisfactory. The probes have also been 
designed so that present Pioneer data processing techniques are applicable. 

A predetection recording scheme has been recommended for the multiprobe 
mission in order to maximize the probability of data capture during probe 
encounter and descent. It is recognized that the predetection recording and 
playback equipment is not presently used on the Pioneer program, since it 
has been used in the past on JPL Mariner programs it is not considered 
specialized. The following material describes the factors associated with 
data recovery, ground equipment limitations, and spacecraft and probe 
designs which maximize use of existing ground hardware and software and 
which minimize data loss. This discussion utilizes parameters from the 
current Atlas /Centaur baseline. 

Spacecraft and Probe Data Characteristics 

Data is obtained from the subsystems and scientific instruments 
and processed into a single binary PCM data stream. Analog data is 
converted into 8 bit digital words. Digital and discrete data are also 
formulated into 8 bit words. 

The spectrum of the telemetry data is kept outside of the tracking 
loop bandwidth of the DSIF receiver by phase modulating a square -wave 
subcarrier with the composite PCM data. The data bit stream is modulo 2 
combined with the subcarrier before phase modulating the RF carrier. Data 
rates and subcarrier frequencies are different for each Pioneer Venus 
vehicle and are summarized in Table 4-6. All are compatible with the DSN 
multiple mission telemetry applications (MMT) and utilize DSIF channel D, 
which is described in JPL document 810-5, DSN /Flight Project Interface 
Design Handbook. 

Prior to subcarrier modulation, the data bit stream is convolutionally 
encoded. The convolutional encoder replaces each data bit generated with 
two parity bits designated P and The value of each parity bit is based 
upon the values of selected data bits previously generated in a 32 bit shift 
register. The code utilized is the familiar Pioneer nonsystematic quicklook 
code* Frame lengths for each of the Pioneer Venus vehicles coded data is 
shown in Figure 4-1 as a function of symbol rate for signal -to-noise ratios 
42.5 dB. Curves are shown for frame lengths of 256 and 512 bits. Perfor- 
mance of the DDA shown in Figure 4-1 assumes that six frames are required 
for frame synchronization and confirmation. 
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TABLE 4-6. SPACECRAFT CHARACTERISTICS 
(CURRENT ATLAS/CENTAUR BASELINE) 


V ehicle 

Bit Rates, 
bps 

Subcarrier 
Frequencies , 
Hz 

Frame 

Length, 

bits 

Mod ulation 

Probe 
B us 

8/’" /2^/"'/2048 
Non integer 
3 < N < 1 1 

32, 768 

256 

PCM/PSK/PM 

Orbiter 

8/1.1/2^/111/2048 
Non integer 
3 < N <11 

32,768 

256 

PCM/PSK/PM 

Large 

Probe 

160/80 ^ 

i 

20,480 

512 

PCM/PSK/PM 

Small 

Probe 

1 

60/30/10 

1 

30,720 

512 

PCM/PSK/PM 


While the vehicle designs are compatible with the DSN MMT system, 
there is the problem of the ground system being out of lock. The out-of-lock 
situation is particularly important to the multiprobe mission where a maxi- 
mum amount of data is sought in a short time interval between encounter and 
destruction. The orbiter mission requires less consideration of the out-of- 
lock situation, due to the repetitive nature of the daily orbit and the large 
amount of scientific data which is stored on board the spacecraft and which 
can be played back repetitively as desired. 

Factors that require the ground data processing system to acquire 
(or reacquire) lock are: 1) initial lockup, 2) channel fades, 3) frame 

deletions, and 4) changing bit rates and data formats. 

Initial lockup is not considered a problem for the probe bus or 
orbiter spacecrafts. A great deal of current data will be available to allow 
accurate frequency predictions. Also, signal levels are sufficient to allow 
ready recognition of the spacecraft signal. Table 4-7 tabulates the margins 
for pure carrier and carrier with data for specific mission phases for all 
Pioneer Venus vehicles. 
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TABLE 4-7. MARGIN SUMMARY (CURRENT 
AT LAS /CENTAUR BASELINE 


Vehicle 

Carrier Margin'll 

Carrier With 
Data Margin 

Probe Bus 



Encounter 

17. 1 

11. 5 

Orbiter 



Orbit Insertion 

1.4 

3.6 

End of Mission 

2. 8 

0. 1 

Large Probe 



Acquisition 
after Blackout 

2. 7** 

1. 4** 

20 km 

2.7** 

3. 5** 

Small Probe 



Acquisition 
after Blackout 

0. 5** 

0.5** 

i 

40 km 

0.6** 

3. 0** 

20 km 

2.6** 

4. 9** 


^Margin referenced to 10. 0 dB SNR in carrier loop 2 B, 


**lncludea 2 dB predetection recording loss. 


Initial lockup for the large and small probes could require more time 
due to carrier frequency dispersions at encounter. These dispersions are 
the result of the combination of long term drift, doppler uncertainty, and 
thermal effects. For this reason: 1) the JPL scheme for predetection 

recording has been recommended, and 2) the stored sequences for both the 
large and small probes provide a 15 min period of unmodulated carrier 
prior to the blackout phase. Predetectioh recording eliminates the require- 
ment for receiver lockup. The unmodulated carrier provides a strong 
signal for a period of time that could be used for a check of the ground 
equipment setup. 
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TABLE 4-8. CONVOLUTIONAL CODED TELEMETRY CHARACTERISTICS 
(CURRENT ATLAS /CENTAUR BASELINE) 


— ^ 

Characteristic 

Probe Bus 
and 

Orbiter 

Large Probe 

Small Probe 

DSIF 

Capability 

Constraint length, bits 

32 

32 

32 

32 (maximum) 

Frame length, bits 

256 

512 

512 

1200 (maximum) 

Coder connection 
ve ctor 

N on s y s te mati c 
quick-look 

Nonsy sterna tic 
quick-look 

Non systematic 
quick-look 

Non systematic 
or systematic 

Code rate 

1/2 

1/2 

1/2 

1/2 

Bit rate, bps 

8/"72^/"'/ 

2048 

160/80 

60/30/10 

2048 (maximum) 
6 (minimum) 

Tail length, bits 

24 

24 

24 

8 to 48 




Th.© large and small probe channel fades are caused by turbulence in 
the Venus atmosphere. An allowance for fades (as derived from the 
Stanford analysis of the Venus atmosphere stochastic effects) has been 
included in the telecommunications link performance. 

F rame deletions are caused by buffer overflow in the DDA daring 
the sequential decoding process. Discussions of the Fano algorithm and the 
associated decoding factors are available in the literature. Table 4-8 lists 
the telemetry characteristics and DSIF capability. The buffer overflow 
problem is reduced by short telemetry frame lengths and low bit rates. 

In addition, the buffer overflow problem on the multiprobe mission is further 
reduced as the predetection recording can be played back at slower than real 
time rates to allow increased computation time per information bit. 


Figures 4-2 and 4-3 portray the data which would be lost due to chang- 
ing data rates in typical large and small probe missions. The loss of data 
is attributable to loss of SSA and DDA synchronization and is equal to approx- 
irnately 3000 bits in every case. Several schemes have been examined to 
minimize or eliminate this source of data loss. These are discussed in a 
separate trade study. The most attractive scheme at present is to provide 
a separate data buffer which would, in parallel with the real time link, 
store data during the reacquisition sequence. This stored data would be' 
interleaved in the telemetry format for replay subsequent to reacquisition. 

The buffer would be utilized during initial acquisition and at every subsequent 
bit rate change. The bit rate changes are required to maximize the data 
which will be returned for a given RF power output level. 

At probe bus encounter, the telemetry symbol rate is 4096 SPS and 
the reacquisition process requires less than 1 sec. 

Telemetry formats for all vehicles have been designed so that format 
changes do not result in loss of ground system lock. All frame sync words 
and tail sequences are identical for all formats. 

Data Handling Interface Methods 

The purpose of this study was to define an optimum data handling 
interface method for gathering data from science instruments and engineer- 
ing equipment on the four Pioneer Venus space vehicles. The particular 
interface to be investigated was that between the data handling subsystems 
and the users. A user is defined as the source of the data to be gathered, 
which may be a science instrument or another engineering subsystem. The 
study was to include all analog and digital data requiring sampling by the 
data handling subsystem; the types of digital data to be considered included 
both serial digital signals and bilevel discrete signals. 

The fundamental objectives and the procedural approach for this 
study were the same as those described for the study of command interface 
methods in subsection 4. 1. First, interface guidelines were established 
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which defined optimum data handling interface features and characteristics 
for scientific type spacecraft. A major guideline was that the interface 
must be sufficiently flexible to handle a multiplicity of science instrument 
and equipment complements with maximum modularity and standardization; 
also, particular emphasis was placed on grounding techniques that provide 
isolation of signal reference grounds so as to enhance data point measure- 
ment accuracy. Then, a survey was conducted to solicit information on 
previously developed data handling subsystem hardware from known sup- 
pliers of space equipment. Details of this survey are reported in subsec- 
tion 4. 3, Using information from the survey, an evaluation of existing 
equipment designs from six different companies resulted in selection of the 
data handling interface hardware developed for the OSO-I program. 

The OSO interface hardware is felt to be an optimum choice for all 
four space vehicles. After the surveyed equipment was evaluated, it 
was found that most of the other equipment designs met portions of the study 
objectives and guidelines to varying degrees. However, the OSO hardware 
was the only interface equipment located that meets all of them without 
modification. The OSO interface hardware consists of standard data input 
modules; these modules are called remote multiplexers in OSO terminology. 
The modules are a modern design and employ custom LSI technology to 
reduce mass and improve reliability. They were developed specifically for 
use on scientific spacecraft. The design of these modules is particularly 
well suited for Pioneer Venus since the interface requirements for these 
four spacecraft are very similar to those for OSO-I. 

The following subsections present a summary description of the 
selected interface design as applied to the Pioneer Venus data handling 
subsystems; a more detailed description may be found in Reference 4-2. 
First, a general description of the design aspects common to both the bus/ 
orbiter spacecraft and to the probes is described. Then, the unique charac- 
teristics of the interface design for each vehicle are discussed separately. 

General Interface Description 

The data handling subsystem accepts both analog and digital input 
data. In addition, it provides output timing signals to user subsystems or 
science instruments in order that they may transfer serial data or perform 
other operations in synchronization with the data handling subsystem. There 
is considerable commonality between input and output circuitry of the bus/ 
orbiter spacecraft and the probes; thus, the input data interface and the 
output timing interface are quite similar for all vehicles. 

Three types of signals are accepted by the data handling subsystems 
of the bus /orbiter spacecraft and the probes: analog, serial digital, and 
bilevel discrete signals. The input multiplexer of the data handling subsystem 
will utilize the same circuitry for all three signal types in both the spacecraft 
and the probes; thus, much of the input specification is the same for all 
subsystems and science instruments on all vehicles. Certain specifications, 
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such as sampling time, will vary with a particular vehicle, its mode of 
operation, and the input signal type. A complete definition of these parameters 
will be made during final system design. 

The data handling subsystem input specifications are summarized in 
Table 4-9. 


TABLE 4-9. DATA HANDLING SUBSYSTEM INPUT SPECIFICATION 


Multiplexer input impedance 
Input current 


Multiplexer ON, sampling 
time 

Multiplexer ON, nonsampling 
time 

Multiplexer OFF 

Input capacitance 

Multiplexer sample time 

Data source failure modes 
Open circuit 

Short circuit to low impedance 
source 


±1.0 pA maximum for -IV s 

< +5. 3 V; +300 pA maximum for 

+5. 3 V S' V. < +17 V 
in 

±0. 1 pA maximum for -1 V ^ 

< +5. 3 V; +300 pA maximum for 

+5. 3 V £ V. < +17 V 
in 

±0. 1 pA maximum for -1 V < 

< +12 V; +300 pA maximum for 

+12 < V. < +17 V 
in 

300 pF maximum (plus up to 
700 pF line capacitance). 

Variable, depending upon operating 
mode (TBD). See text. 


Undefined output 

-50 to +50 V with no damage; 
other channels are not affected. 
For voltage outside this range, 
special precautions must be taken 
during the design phase to protect 
the multiplexer. 
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Data source requirements differ with the signal type and, for analog 
signals, with the A/D conversion accuracy required. These data source 
output requirements are summarized in Table 4-10. Individual signal types 
are discussed below. 

The data handling subsystem samples analog inputs and converts them 
into serial digital words for telemetering to the ground. In the bus/orbiter 
spacecraft, analog signals are converted into 8 bit words; in the probes, 
they are converted into 10 bit words since the accuracy requirement is 
greater for certain specified inputs. 

The term analog as used here covers two different types of measure- 
ments. One is a dc voltage with a range of 0 to +5. 12 V, which would 
typically be the output of a buffer amplifier in a vehicle subsystem or 
science instrument. As measured, the other is also a 0 to +5. 12 Vdc signal, 
but it is generated by supplying a constant current (1 mA) to a variable 
resistor ''thermistor, potentiometer, etc. ) in a vehicle subsystem or 
science instrument. The current is generated in the telemetry subsystem 
and is gated to the variable resistor during the sampling interval on the 
multiplexer input line assigned to that particular analog (resistance) 
measurement. The variable resistor must operate over a ranee of 0 to 
5.12 kD. ® 

Each multiplexer can accept a signal return line, from a given using 
subsystem or science instrument, for differential measurement of analog 
data signals. This line is terminated with a high impedance inside the data 
handling subsystem, ensuring essentially no current flow, and is used as an 
analog reference return. 

Discrete bilevel signals to be telemetered are sampled and 
assembled by the spacecraft (probe) multiplexers into 8(10) bit words for 
transmission. In addition to accepting discrete bilevel signals, bulk scien- 
tific data can also be accepted in 8 (10) bit bytes on 8 (10) parallelTines dur- 
ing the time interval defined by a read envelope. Multiple 8(10) bit bytes 
can share these 8 (10) lines, resulting in the data being located at the 
desired positions throughout a minor frame if the falling or leading edge 
of the read envelope is used to update an 8 (10) bit output register within 
the science instrument. Minor frame sync is provided by the data handling 
subsystem to enable the science instrument to synchronize the gathering 
of experiment data, and thus to distinguish one 8 (10) bit byte from another. 

For telemetering large quantities of data from an individual space- 
craft subsystem or science instrument, a serial digital data interface is 
preferred as compared with the use of a parallel data transfer via multiple 
bilevel digital inputs; this is because the serial approach reduces multiplexer 
hardware and simplifies control logic. However, analog and discrete bilevel 
inputs are also provided for use as required. 
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TABLE 4-10. DATA SOURCE OUTPUT REQUIREMENTS 


Analog data 


Data voltage range 

0 to +5. 120 V 

Source impedance 

10 kf2 maximum, 8 bit accuracy (100 ohms 
maximum, 10 bit accuracy, probes only) 

Grounding 

Users shall supply their local signal ground 
to the multiplexer as a reference. This line 
is terminated with a high impedance inside 
the data handling subsystem* Inputs will be 
handled differentially with respect to this 
signal ground. 

Bilevel discrete data 


Logical 0 

- 1 to +1 V 

Logical 1 

+4 to +17 V 

Source impedance 

10 maximum 

Serial digital data 


Logical 0 

- 1 to +1 V 

Logical 1 

+4 to +17 V 

Voltage rise and fall 
times (to or beyond 
logic threshold) 

3 psec maximum with 1000 pF capacitive load 
(300 pF maximum multiplexer capacitance plus 
700 pF maximum line capacitance (<14 ft of 
cable) 

Delay time 

Data bit 1 shall be at or beyond logic threshold 
within 40 psec after user's read envelope 
input buffer's collector output switches to 
logic 0 (logic ”0" to "1" transition at input). 
Data bits 2 through 8 (2 through 10 in probes) 
shall be valid within 6 psec after user's read 
clock buffer's collector output switches to 
logic 1 (logic "1" to "0" transition at input). 

Data sync 

Data transitions shall occur with the 1 to 0 
transition (trailing edge) of clock pulses 
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NRZ serial digital data sources are provided with a read envelope 
and a read clock signal in synchronism with which an 8 (10) bit word group 
is serially shifted to the multiplexers. Each serial user should enable the 
common read clock signal, with the unique read envelope signal provided to 
him for data readout at the correct times. Internal submultiplexing can be 
performed by the user in 8 (10) bit bytes to time share one data channel 
if the data readout is properly synchronized with the data handling timing 
signals (e. g. , minor frame or major frame sync) so that the data can be 
identified in ground processing. Alternately, multiple 8 (10) bit groups 
can share a common data bus output (i.e. , wire ORing the data channels 
together) through proper steering by unique read envelope signals, one for 
each 8 (10) bit group. 

The data handling subsystem provides read envelope signals to users 
for gating of their bilevel discrete outputs; it provides both read envelope 
and read clock signals to users for gating of serial digital outputs. In 
addition, various clock frequencies are provided for general use to vehicle 
subsystems or science instruments. Output specifications for the data 
handling subsystem are summarized in Table 4-11. 

Read envelope signals are provided to bilevel data sources and to 
serial data sources. Bilevel data sources may use this signal for synchroni- 
zation or, in conjunction with frame sync signals, for time sharing output 
data lines within the user subsystem or instrument. Serial data sources 
may also use the read envelope signal in this manner; however, it also 
defines the time during which serial data must be clocked out to the data 
handling subsystem by the read clock signal. 

Read clock signals are provided to all serial data sources and are 
used to serially shift data to the data handling subsystem. 

In general, the frequency and pulsewidth of the read clock and read 
envelope signals will vary with the particular vehicle and also with the 
operating mode if multiple bit rates are used; complete definition will be 
made during final system design. 

The data handling subsystem provides major frame sync, minor 
frame sync, and word sync signals such that submultiplexing of data can be 
accomplished within a user subsystem or science instrument. These signals 
can also be used to notify a user that he will be sampled, at a fixed later 
time, in order to provide him time to get his data ready. Only square wave 
frequency sources that can be derived from a simple countdown chain will 
be provided. The key output frequencies will have a period equal to the major 
frame period, the minor frame period, the word period, and the bit period. 

If needed, other frequencies can easily be derived within a science 
instrument by using one of these signals, which represents the minimum 
resolution desired, to drive a countdown chain within the science instrument; 
another one of these signals (such as major frame sync) can be used to 
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reset this counter at the appropriate time in order to maintain a proper 
phase relationship with the clock. In using this two signal interface, one 
could greatly reduce the number of interface wires and interface buffers 
between the data handling subsystem and all of the using subsystems and 
instruments. On the other hand, the complete countdown does exist within 
the data handling subsystem and any of its outputs could be provided to an 
instrument if needed. 

In addition to the above frequencies which, in general, will vary with 
changes in the bit rate or data format, at least one fixed frequency (e.g. , 
2048 Hz) will be provided by. the data handling subsystem. 

Where multiple bit rates are employed (i.e. , where bit rates are 
changed for different operating modes), "bit rate mode" signals will be 
made available to users to indicate when a particular bit rate is in use. 
These signals can be used to inhibit selected frequencies when a user 
subsystem is not being sampled by the data handling subsystem. 

Unique Spacecraft Characte ristics 

The data handling subsystem of the bus/orbiter spacecraft provides 
the means for retrieval of spacecraft status and experimental data. The 
subsystem provides full redundancy in all mission critical areas and 
achieves high reliability. Redundant signals will be connected to two dif- 
ferent remote multiplexers. In case of a single multiplexer failure, the 
redundant line will still be sampled. 

All remote multiplexer units are identical and interchangeable. 

Each unit may be separately programmed to operate in one of four different 
modes by external wiring of four unit connector pins. For mode definition, 
see Table 4-12, Table 4-13 presents this same mode data in a different 
format. 


The four modes define which of the 32 input channels will be used for 
the three different types of input data. Table 4-13 indicates the type and 
quantity of each input in each of the four modes. In the mode 1 configuration, 
all 32 inputs are bilevel digital data. In the mode 2 configuration, there are 
24 bilevel digital inputs and five inputs which may be either analog or serial 
digital. In the mode 3 configuration, there are two different input choices; 
these are essentially two separate submodes that require specific program- 
ming of the fixed memory in the telemetry processor. In one of these sub- 
modes, there are 16 bilevel inputs and 14 inputs which may be analog or 
serial digital. In the mode 4 configuration, there are 16 analog inputs and 
16 inputs which may be analog or serial digital. 

It may be noted from the tables that the same inputs may be used for 
analog, bilevel, or serial data, depending on the mode selection. Therefore, 
several multiplexer characteristics are common to any type of input as 
previously summarized in Table 4-9. 
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TABLE 4-11. DATA HANDLING SUBSYSTEM 
, OUTPUT SIGNAL SPECIFICATION 


Read envelope 

signal 


Waveform 


Rectangular 

Palsewidth 
F requency , 


Variable, depending upon operating mode 
(TBD). See text. 

Fanout capability 

Two (with standard input buffer, Hughes 
Part No. 908974) 

Logical 0 


0 V (referenced to the data handling subsystem 
signal return) through 5*3 ±Z. 9 source 

impedance 

Logical 1 


+13 ±3 volts capable of supplying 4 mA. 

Voltage rise time 
(10 to 90 percent) 

2. 5 [xsec maximum. Load equals 700 pF line 
capacity in parallel with a standard input 
buffer (or 30 kf2). This corresponds to a total 
line length < 14 ft. 

Voltage fall time 
(90 to 10 percent) 

15 psec maximum. Load equals 700 pF line 
capacity in parallel wilh a standard input 
buffer, Hughes Part No, 908974. 

Short circuit 
protection 

Current limiting is provided for protection 
against shorts to ground 

Read clock signal 


Waveform 


Rectangular, gated 

Frequency 


Variable, depending upon operating mode 
(TBD). See text. 

Fanout capability 

Twelve (with standard input buffer, Hughes 
Part No. 908974) 

Logical 0 


0 V (referenced to the data handling subsystem 
signal return) to +1 V while sinking 100 pA 
maximum 

Logical 1 


+13 ±3 volts capable of supplying 24mA 

Voltage rise time 
(10 to 90 percent) 

2.5 psec maximum. Load capacitance shall be 
3000 pF maximum 
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Table 4-11 (concluded) 


Voltage fall time 
(90 to 10 percent) 

5. 0 psec maximum. Load capacitance shall 
be 3000 pF maximum. 

Number of clock 
pulses 

Eight (ten in probes) per read envelope 

S/stem clock signals 


Waveform 

Square wave with 50 percent ±2* 5 fxs duty 
cycle 

F requency 

Multiple and variable. See text. 

Fanout capability 

Two (with standard input buffer, Hughes Part 
No, 908974 

Logical 0 

0 to +1 V 

Logical 1 

+14 ±2 V capable of supplying 4 mA 

Voltage rise and 
fall times 

2* 5 |jLsec maximum with 3000 pF maximum 
load capacity 

Short circuit 
protection 

Current limiting is provided for protection 
against shorts to ground 

Bit rate mode signals 


Waveform 

Logical 0 or logical 1, depending upon 
operating mode. 

F anout capability ^ 


Logical 0 


Logical 1 


Voltage rise time 

> Same as read envelope signal 

Voltage fall time 


Short circuit 
protection J 



4-38 



4-39 


TABLE 4-12. TELEMETRY REMOTE MULTIPLEXER INPUT OPTIONS 


Input 

Address 

MSB LSB 



Mode 1 

Mode Z 

Mode 3 

Mode 4 . ! 

K ead 
Envelope 
Selection 

Read 

i:iock 

Present 

Dataj 

Type^ 

Sampled 

Input 

Channel(s) 

Applicable 

Current 

Bus^ 

Data 

Type 

Sampled 
Input .j 
Channel(s) 

Applicable 

Current 

Bus^ 

Data 

Type 

Applicable 
Input 2 
Channel(»)f 

Applicable 

Current 

Bus^ 

Data 

Type 

Sampled 

Input 

Channel(s) 

Applicable 
Cu r rent 
Bus^ 

oooop 

0 

Yes 

P 

24-31 

- 

P 

24-31 


P 

24-31 


A or S 

0 

1 

00001 

I 

Yes 

P 

16-23 

- 

P 

16-23 

- 

p4 

16-23 

_ 

A or S 

1 

1 

00010 

2 

Yes 

P 

8-15 


P 

8-15 

- 

A or S 

2 

1 

A or S 

2 

1 

00011 

3 

Yes 

P 

0-7 

- 

A or S 

3 

1 

A or S 

3 

1 

A or S 

3 

1 

00100 

4 

Yes 




A or S 

4 

2 

A or S 

4 

2 

A or S 

4 

2 

00101 

5 

Yes 




A or S 

5 

2 

A or S 

5 

2 

A or S 

5 

2 

00110 

6 

Yes 




A or S 

6 

2 

A or S 

6 

2 

A or S 

6 

2 

00111 

7 

Yes 




A or S 

7 

2 ■ 

A or S 

7 

2 

A or S 

7 


01000 

a 

Yes 







A or S 

8 

3 

A or S 

8 

3 

01001 

9 

Yes 







A or S 

9 

3 

A or S 

9 

3 

QlOlO 

10 

Yes 







A oj S 

10 

3 

A or S 

10 

3 

OiOl 1 

H 

Yes 







A or S 

I J 

3 

A or S 

1 ] 

3 

01100 

12 

Yes 







A or S 

12 

3 

A or S 

12 

3 

OllOI 

13 

Yes 







A or S 

13 

3 

A or S 

13 

3 

OHIO 

14 

Yes 







A or S 

14 

3 

A or S 

14 

3 

oiin 

IS 

Yes 







A or S 

15 

3 

A or S 

15 

. 3 

10000 

- 

No 







a\ 

16 

4 

A 

16 

4 

10001 

-- 

No 







A I 

17 

4 

A 

17 

4 

lOOlO 

: 

No 




1 



A 1 

18 

4 

A 

18 

4 

10011 

- 

No 







A I 

19 

4 

A 

19 

4 

10100 

! 

No 







A> ^ 

20 

5 

A 

20 

5 

lOlOl 

“ 

No 







A 1 

21 

5 

A ; 

•21 

5 

10110 

--- 

No 







A 1 

22 

5 

A 

22 

5. 

lOIll 

-- 

No 







A I 

23 

3 

A 

23 

5 

1 1000 

-- 

No 







' 1 



A 

24 

6 

11001 

-- 

No 










A 

25 

6 

11010 


No 










A 

26 

6 

noil 

- 

No 


1 








A 

27 

6 

moo 

-- 

No 










A 

28 

6 

nioi 

- 

No 










A 

29 

6 

11110 

- 

No 










A 

30 

6 

mil 

-- 

No 

i 









A 

31 

6 

Mode pin 
Connection 

A Lo return; B to return 

A to .return; B - open circuit 

A = open circuit; B 

to return 

A = open circuit; 
B = open citcuit 


is parallel bilevel dii’ital, ''S’’ is serial digital, "A" is analog. 

Input channels 0, 1, and Z are not used in mode Z and channels 0 and 1 are not used in mode 3, 

Use of a current bus for a signal conditioned channel commits the other channels associated with that bus to aUo be used for signal conditioning. 
In mode 3 input channels 16 to 23 may be used for parallel bilevel data (address 0000 1) or analog data (addresses 10000-10111), 



TABLE 4-13. TELEMETRY REMOTE MULTIPLEXER INPUT OPTIONS 


Serial Inputs 

Analog Inputs 

Parallel Bilevel Words 

Mux 

Number of Input 

(8 -bit bytes) 

(0 to +5. IZ volts) 

(8 -bit bytes) 

Mode 

Lines Used 

16 

16 

0 

4 

32 

15 

17 

0 

4 

32 

14 

18 

0 

4 

32 

14 

8 

1 

3 

30 

14 

0 

2 

3 

30 

13 

19 

0 

4 

32 

13 

9 

1 

3 

30 

13 

1 

2 

3 

30 

12 

20 

0 

4 

32 

12 

10 

1 

3 

30 

12 

2 

2 

. 3 

30 

11 

21 

0 

4 

32 

11 

11 

1 

3 

30 

11 

3 

2 

3 

30 

10 

22 

0 

4 

32 

10 

12 

1 

3 

30 

10 

4 

2 

3 

30 

9 

23 

0 

4 

32 

9 

13 

1 

3 

30 

9 

5 

2 

3 

30 

8 

24 

0 

4 

32 

8 

14 

i 

3 

30 

8 

6 

2 

3 

30 

7 

25 

0 

4 

32 

7 

15 

1 

3 

30 

7 

7 

2 

3 

30 

6 

26 

0 

4 

32 

6 

16 

1 

3 

30 

6 

8 

2 

3 

30 

5 

27 

0 

4 

32 

5 

17 

1 

3 

30 

5 

9 

2 

3 

30 

5 

0 

3 

2 

29 

4 

28 

0 

4 

32 

4 

18 

1 

3 

30 

4 

10 

2 

3 

30 

4 

1 

3 

2 

29 

3 

29 

0 

4 

32 

3 

19 

1 

3 

30 

3 

11 

2 

.3 

30 

3 i 

2 

3 

2 

29 

2 

30 

0 

4 

32 

2 

20 

1 

3 

30 

2 

12 

2 

3 

30 

2 

3 

3 

2 

29 

1 

31 

0 

4 

32 

1 

21 

1 

3 

30 

1 

13 

2 

3 

30 

1 

4 

3 

2 

29 

0 

32 

0 

4 

32 

0 

22 

1 

3 

30 

0 

14 

2 

3 

30 

0 

5 

3 

2 

29 

0 

0 

4 

1 

32 
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The signal input capability of the telemetry subsystem is flexible. 

It can be changed by the addition or deletion of remote multiplexers to 
accommodate requirements for either more or less signal inputs. 

When redundancy is required, the signals must be connected to two 
different multiplexers. Cross - strapping at this interface is not normally 
necessary since there is complete cross-strapping between the remote 
multiplexer and the PCM encoder. For cases where cross - strapping of 
multiplexer inputs may be advantageous, a description of the recommended 
techniques for analog, serial digital and parallel digital (discrete) data 
inputs may be found in Reference 4-2. 

Unique Probe Data Handling Characteristics 

The data handling subsystem of the probes differs from that of the 
bus/orbiter spacecraft in two principal respects; first, because of the size, 
the multiplexing is centralized rather than distributed among remote multi- 
plexers; and second, as specified, the probe subsystem has the capability 
for converting analog input signals into 10 bit digital words with an accuracy 
of ±1.0 percent. The latter results in an analog data interface definition 
different from that of the spacecraft for those inputs requiring high accuracy 
conversion. 

The data handling multiplexer has 112 input channels in the large 
probe and 52 input channels in the small probe. The distribution of analog, 
bilevel digital, and serial digital channels is given in Table 4-14. The 
multiplexer provides special circuitry for analog inputs requiring high 
accuracy A/D conversion. The A/D converter in the data handling subsystem 

TABLE 4-14. PROBE DATA HANDLING MULTIPLEXER INPUT PROVISION 


Input Type 

Provision for Inputs 

Large Probe 

Small Probe 

Analog 



10 bit accuracy 

32 

8 

8 bit accuracy/10 bit resolution 

44 

20 

Bilevel digital 

28 

20 

Serial digital 

8 

4 

Totals 

112 

52 
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Analog Data 
to Data Handling 
Subsystem 


* Rl, R2 Selected for 0,000 to 5.120 Volt Output Range 


FIGURE 4-4. HIGH ACCURACY ANALOG DATA OUTPUT CIRCUIT 
RECOMMENDATIONS 
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converts the sampled analog data into a 10 bit serial word format. The 
bilevel digital data are formatted into 10 bit digital words, as are the serial 
digital data inputs, in a controlled time sequence. All three types are 
combined, encoded, and transmitted as a sequence of 10 bit serial data words 
to both the probe bus and the communications subsystem. 

Analog signals to be telemetered are sampled by the multiplexer 
to generate a 10 bit telemetry word for transmission. Within the full-scale 
A/D conversion range, certain analog input signals will be converted with 
an accuracy of ±5 mV or ±0. 1 percent of full scale (i. e. , i2. 5 mV offset 
and ±2.5 mV quantization error). All other analog inputs will be converted 
with 10 bit resolution, but with ±20 mV or ±0.4 percent of full scale 
accuracy (i.e., ±17-5 mV offset and ±2. 5 mV quantization error). 


The data source requirements for high accuracy inputs are as follows: 


1) Data voltage range 

2) Source impedance 

3) Grounding 


Orbiter Data Storage Analysis 


0 to +5. 120 V 

100 ohms maximum (see recommended 
circuit. Figure 4-4) 

Users shall supply their local signal 
ground to the multiplexer as a reference. 
This line is terminated with a high 
impedance inside the data handling 
section. High accuracy inputs will be 
handled differentially with respect to 
this signal ground. 


Data storage is required on the orbiter spacecraft. Overall require- 
ments for the data storage units have been derived from data ratio associated 
with different phases of the Pioneer Venus mission. Trade studies were 
then conducted on memory technologies for data storage use. 

Requirements Analysis 


Overall requirements for the data storage unit have been developed 
from an examination of science data requirements and the mission operation. 
The material presented is based upon the current Atlas/Centaur baseline: 

1) The maximum storage data rate is a function of the science data 
requirement. This maximum rate always occurs around the 
periapsis point during an occulted periapsis pass. The present 
payload rate requirement is 490 bps, which is exclusive of 
overhead for sync words, engineering data, format inefficiencies, 
etc. The derived rate requirement (discussed later) is 640 bps 
which includes overhead factors. 
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FIGURE 4-5. TELECOMMUNICATIONS PERFORMANCE DURING ORBIT 
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2) The minimum data storage rate occurs after the apoapsis 
phase. The present science data rate requirement for this 
phase is 7.67 bps which is again exclusive of overhead, etc. 

3) The minimum /maximum playback (or dump) rates are constrained 
by the downlink design which is capable of rates between 8 and 
2048 bps in multiples of 2”. 

4) The minimum data storage capacity requirement is determined 
by data requirements during the occulted periapsis passes. 

The derived requirement (discussed later) is 890,880 bits. 

5) The data storage unit can be operated in a simplex mode in that 
the capability to concurrently read and write is not required. 

6) Graceful degradation is provided by supplying the unit in two 
separately operated modules, each of which provides half of 
the total required storage capacity. 

As a result of the hardware study which follows, magnetic core 
storage has been shown to be the most acceptable implementation. Due to 
core memory addressing register technology, data storage capacity 
generally is designed in multiples of 2*^ times the storage word size. 

The Pioneer Venus telemetry word size is 8 bits and the minor frame 
length is 256 bits; so the storage word size should be an integer (N) 
times 8 where M(Nx8) = 256 and M is also an integer. 

As a result of countdown circuitry design considerations, data rates 
are also in 2 submultiples. 

i 

To minimize circuitry onboard the spacecraft, it is desirable to 
minimize the total number of different data formats which would be 
required to store or transmit in real time. 

Figure 4-5 portrays the downlink telecommunications performance 
for the entire orbit phase. ^ The data rate for the first 35 days in orbit is 
1024 bps, and for the next 40 days it is 512 bps, both of which meet or 
exceed real time science data requirements. When the link capability 
is reduced to 256 and finally 128 bps, the science requirements exceed the 
real time transmission capability and the excess is stored for later trans- 
mission. Earth occultation periods and eclipses must also be accounted 
for with storage and their requirements are also analyzed. 

Figure 4-6 depicts the minimum science data storage requirement 
for an orbit late in tiie mission when the downlink capability is 128 bps. 

As shown, five data formats are utilized to provide experiment sampling. 

In addition, four data rates are required, none of which are binary multiples 
of each other. 
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TABLE 4-15. PERIAPSIS SCIENCE DATA FORMATS 



^Implemented sample rates inclades 16 percent overhead provision for frame sync and engineering data transmission. 






The storage requirement for this minimum implementation is 
510,000 bits. This provides storage only for the science instrument data, 
with no provision for frame sync or engineering data. In addition, the bit 
rates require extra countdown circuitry as they are not binary submultiples. 

Alternate format characteristics are tabulated in Table 4-15. The 
first format "A" is sampled at 128 bps, and the science instrument sampling 
requirements along with the implemented provisions are shown. For all 
formats, the implementation exceeds the science requirement. Data rates 
of 170-2/3 and 341-1/3 for formats "C" and "D” were selected because 
they are integer fractions of 512 bps (1/3 and 2/3' s, respectively). The 
data sampling rate includes a minimum 16 percent overhead allowance for 
transmission of frame sync and engineering data. The implementation 
penalty associated with tiie overhead and "nice" data rates is 129,936 bits 
(or a total storage requirement of 510, 000 + 129,936 = 639, 936). 

An additional alternative would be to implement only binary bit 
rates. The results of this and the previous alternative are shown by cross 
hatching on Figure 4-7. This alternative, though costing 112,956 bits 
(total 752,892), is attractive as extra bit rate countdown circuitry can be 
eliminated and the entire format "D" can be deleted. 

The maximum occultation period is 23 minutes. It occurs near, but is 
not centered on, perlapsis. For computation of storage requirements, 
occultation is assumed periapsis centered as it represents the worst case. 
From Figure 4-7 it can be seen that data will be stored for part of formats 
"A" and "C" and all of format "D/E." The worst case number of bits 
required to be stored are 890,880. 

Alternate configurations would minimize data storage required at 
the expense of additional data rates and formats. For example, if format 
"D" was utilized and two additional bit rates (Figure 4-7) were implemented 
(A + C and A + D), approximately 174,080 bits could be saved and the 
occulted periapsis storage would be 716,800 bits. 

The maximum storage rate is reached when format "E" is sampled 
at 512 bps and format "A" is sampled at 128 bps. The sum is 640 bps 
which is 5/8 of 1024. 

An additional use of the data storage could occur at the apoapsis phase. 
Data storage at this phase could accommodate planned DSN outages, etc. 

The apoapsis phase is defined as the apoapsis point ±8 h. The science 
data requirement is 7.67 bps during apoapsis. This requirement is met 
with a spacecraft standard 16 bps clock which allows sample margin 
(50 percent) for sync and engineering data. At 16 bps, 57,600 bits would 
be stored per hour, or a total of 921,600 bits would be stored for 16 h. 

An alternative configuration would utilize a nonbinary bit rate of 
10-2/3 bps (which allows ample overhead provision), or for 16 hours would 
require 6 14, 400 bits of storage. 
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Typical storage capacities are shown in Table 4-16. In the region 
of interest, selectable capacities are 524,288; 589,824; 786,432; or 
1,048,5 76 bits. Since it is desirable to iniplement the design in two 
independent half-capacity modules in order to provide graceful degradation 
in the event of failure, the 589,824 configuration can be eliminated. 

Figure 4-8 relates the various storage capacities to the range of 
storage requirements. It can be seen that, in terms of spacecraft design 
minimization, the 1,048,576 configuration is optimum as it meets storage 
requirements for all mission phases without additional data rates (except 
for occulted periapsis 640 bps) or formats. The two half- capacity modules 
would contain 524,288 bits. 

A viable alternative to the 1,048,576 configuration is 786,432. 
Spacecraft cost for this alternative consists of, at worst case, the inclusion 
of nonbinary data rates and an additional data format to handle the occulted 
periapsis phase. Depending upon the length of time apoapsis data is to be 
stored, a nonbinary rate may be desirable anyway for this phase. 

Table 4-17 relates data storage implementation to spacecraft 
requirements for bit rates and formats for the two memory configurations 
considered (1,048,576 and 524,288. 

The length of time required for data storage playback is determined 
by the downlink data rate. At the end of the orbiter mission, this data rate 
is 128 bps. At times other than at periapsis, the science data requirement 

TABLE 4-16. CORE DA TA STORAGE CAPACITIES 


Total 

Words 


Word /Me 

mory Size 


8 Bit 

16 Bit 

24 Bit 

32 Bit 

2,048* 

- 


49, 152 

65,536 

4,096* 

- 

65,536 

98,304 

131,072 

8, 192* 

65,536 

131,072 

196,608 

262, 144 

16,384* 

131,072 

262, 144 

393,216* 

524,288 

24,576 

196,608 

393,216 

589, 824 

786,432 

32, 768* 

262, 144 

524,288 

786,432 

1,048,576 


^Binary Multiples — best and most effective. 
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TABLE 4-17. DATA STORAGE IMPLEMENTATION REQUIREMENTS 



Memory Configuration 

Requirements 

1,048,576 

786,432 

Bit rates 

8-Z048 iii 2 ^ min 
plus 640 bps 

Additional rates of 
170-2/3, 341-1/3, 
and 10-2/3 

F ormats 

No additions 

Possible addition of 



a single periapsis 
format 


is approximately 8 bps. Allowing another ZO bps for engineering data 
transmission, etc. , the remaining capability of 100 bps is available for 
dumping data from the storage unit. The length of time required for playback 
at this rate is approximately 3 h. Playback in this time interval is attrac- 
tive as it allows complete playback of all stored periapsis data subsequent 
to periapsis and within the same Goldstone pass. This feature allows con- 
sideration of deletion of some non-Goldstone tracking periods (Canberra 
or Madrid) as all mission critical activities can be conducted within a single 
Goldstone pass. 

Utilization of this data storage unit during the time that Goldstone is 
out of view will assure that important scientific data is not lost in the event 
that reduced DSN tracking is required. The period of time between Goldstone 
rise and the start of periapsis activities is sufficient to play back all data 
recorded during the apoapsis period. 

The requirements analysis arrived at the following conclusions: 

1) The recommended data storage size is 1,048, 576 bits. This 
size is attractive as it meets data storage requirements, with 
adequate overhead, for the periapsis and apoapsis phases. It is 
also a size that is desirable from a hardware implementation 
standpoint in that there are half capacity units (524, Z88 bits) 
available as existing hardware; spacecraft hardware is minimized 
as additional bit rates and formats are not required. 

Z) F or a small increase in spacecraft hardware, an alternate mem- 
ory configuration of 786,432 total bits is acceptable. 

3) Use of the data storage at apoapsis wQuld allow reduction in DSN 
tracking requirements and consequent cost savings. 
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Hardware Implementation Analysis 


This subsection reports a tradeoff analysis of data storage technologies 
for the orbiter spacecraft. The technologies reviewed were magnetic core, 
magnetic plated wire, semiconductor bipolar, and semiconductor static 
and dynamic MOS. Magnetic tape recorders were not considered due to the 
moderate storage requirement (=393 K bits) and because of the high mass, 
low reliability and constant change in center of gravity normally associated 
with their use. The basis for the conclusions in this study are that cost, 
mass, and reliability are of prime importance. Other items of significant 
importance are power, magnetic cleanliness, and use of existing technology. 

For data handling memories in the order of 10^ to 2 x 10^ bits, either 
the use of a magnetic core memory or a MOS dynamic memory with a hidden 
refresh cycle is feasible. However, magnetic core was chosen for use on 
Pioneer Venus because the technology has been proven on past space programs 
and thus offers the best approach in terms of technical risk. Table 4-18 
summarizes some of the parameters of the different types of memories 
investigated in this study. 

The various memory technologies investigated in this study are 
briefly discussed in the following sections. 

Magnetic Core. Memories consisting of magnetic cores are usually 
constructed in two basic sections, electronics and core stack. The core 
stack is usually a three-dimensional array organized in stacked planes. 

The electronics usually account for about 50 percent of the volume and may 
be considered to fall within three major categories: 

1) Address electronics (X and Y) 

2) Bit electronics (Z) (read and write) 

3) Power control (strobing and conversion) 

A major feature of core memories is that they are nonvolatile and 
therefore can be power strobed only when access is needed. The typical 
access time is from 1 to 3 psec. The power during access is very large 
and in the order of 50 W. If the memory is operated at low data rates 
(i.e. , less than 100 K bps), it can be organized such that access is once 
every 20 to 40 bits and therefore the average power consumption could be 
less than 1 /2 W. 

Magnetic cleanliness requirements may present some moderate 
problems to magnetic core memories. If the requirements are not too 
severe (i.e. , in the order of 5 gamma at 3 ft), careful packaging techniques 
and selection of materials can be used to reduce the magnetic fields to 
acceptable levels. 
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TABLE 4-18* SUMMARY OF DATA STORAGE TECHNOLOGIES 



Magnetic 

Semiconductor 

Parameter 

Core 

plated 

Wire 

Bipolar 

MOS 

Static 

MOS 

Dynamic 

Nonvolatile 

Yes 

Yes 

No 

No 

No 

Power 

Low 

Lowest 

Highest 

High 

Moderate 

Mass 

Moderate 

Moderate 

High 

Moderate 

Lowest 

Space 

experience 

High 

Low 

Low 

Low 

Low 

Ability to 
achieve 
magnetic 
cleanliness 

Moderate 

High 

High 

Highest 

Highest 

Radiation 

tolerance 

High 

Highest 

High 

Moderate 

Moderate 

Technical 

risk 

Low 

Moderate 

Low 

Low 

Moderate 

Cost 

Lowest 

Highest 

High 

Moderate 

Moderate 

Potential 
availability of 
existing 
hardware 

Highest 

Moderate 

Low 

Low 

Low 


Size and mass of a custom designed random access core memory in 
the range of 100 K bits to Z megabits, with Z8 V power supply and using 
standard small cores, should fall in the range of Z* 3 to 4- 5 kg (5 to 10 lb) 
and require a volume between 8Z0 to Z460 cm^ (50 to 150 in^). These 
quantities depend primarily upon the memory configuration and associated 
electronics, and to a much smaller extent on the quantity of storage bits. 

Magnetic Plated Wire> Plated wire memories are constructed 
similar to core memories (i*e. , the electronics are separated from the 
stack). Organization of plated wire memories tends to prefer long internal 
word lengths, compared to core, in order to have an efficient configuration. 
Some major features of plated wire memories are that they are nondestruc- 
tive readout, nonvolatile, and require lower drive currents than core 
memorie s . 
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Magnetic cleanliness should be easier to achieve with plated wire 
than with core memories primarily because of the lower drive currents; 
however, design difficulties may be encountered if ultra magnetic cleanli- 
ness is required. 

Size and mass should be about 80 percent of an equivalent core 
memory because both the stack and the lower current drive electronics 
can theoretically be smaller and lighter in weight. However, a plated wire 
memory may be larger and weigh more than an equivalent core memory, 
depending upon the particular memory configuration and organization. 

The cost of a plated wire memory is currently two to three times 
that of an equivalent core memory. This is primarily due to a limited 
demand at the present time for this type of memory and the consequent 
lower production and manufacturing experience. 

Bipolar Semiconductor Memories . Bipolar semiconductor memories 
can be constructed in almost any desired word length because the semicon- 
ductor chips usually consist of 64 to 128 words 1 to 4 bits in length. Semi- 
conductor memories are volatile and must have power applied continuously 
in order to retain their data contents. Bipolar memory devices are usually 
relatively small (e.g. , 256 bits). To construct a megabit memory using 
these devices, approximately 4000 chips would be required. Using an 
optimistic product mass of 3. 2 kg per 1000 integrated circuits, it appears 
that a bipolar memory would be very heavy and in the order of 11 to 14 kg 
(25 to 30 lb). Because of the high mass, bipolar memories are not 
recommended at this time. 

MOS Semiconductor Memories . MOS semiconductor memories can 
divided into two general groups, static and dynamic. Static memories act 
like a standard storage device when power is applied, but they use more 
power and have a lower bit density than dynamic memory devices. Dynamic 
memories must be periodically refreshed in order to maintain their data 
contents. Because die packing density of a dynamic memory is at least 
twice as great as that of a static memory device and since the required 
refresh circuitry is minimal, a dynamic memory is preferred. Assuming 
a 2048 bit dynamic MOS chip, the mass of a megabit memory is calculated 
approximately as follows: 



kg 

(ib) 

Power supply 

0.4 

(1.0) 

Memory, at 3, 2 kg/1000 IC 

1 . 6 

(3.5) 

Refresh, at 10 percent of memory 

0. 2 

(0.4) 

Totals 

2.2 

(4.9) 


f ^ 

\J 
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Power requirements of dynamic MOS memories running at slow 
access times is dependent on the refresh period. However, for a megabit 
memory operating at low data rates, the power is estimated to be approxi- 
mately 1 to 2 W for the memory and approximately 0. 5 W for the refresh 
circuits. When the inefficiency of the power supply is included, the total 
power for this type of memory is estimated to be about 4 to 5 W. 

Magnetic cleanliness requirements are easily met for semiconductor 
memories because of the low operating currents. 

Environmental constraints for MOS dynamic memories are usually 
limited by radiation considerations. Radiation tolerance for these parts is 
typically 10^ to 10^ rads (Sj) of radiation before failure. 

Probe Data Storage Hardware 

This section analyzes the types of read /write memory for data 
storage use on the probes* Because of the considerable differences 
in storage requirements between the orbiter and the probes (approximately 
393 kilobits for the orbiter compared to 4 kilobits for the large probe), a 
separate study was warranted; the study was initially reported in Ref- 
erence 4-4. 

The study determined that semiconductor read/write memories should 
be used on the probes, and that suitable memories already exist and are now 
being qualified for spacecraft use* However, the state of the art in semi- 
conductor memories is advancing so rapidly that better devices may well be 
available by the time the final probe design is undertaken. 

The Pioneer Venus baseline design requires that 4096 bits of data be 
stored in the large probe, during the entry deceleration, for transmission 
later in the descent; the small probes require storage of 612 bits of data. 

An investigation was conducted to deternrdne the type of memory best suited 
to store these data. Factors considered in selection of a memory included 
cost, mass, power consumption, dimensions, availability, ability to survive 
the probe entry deceleration, radiation hardness, and the possibility of com- 
monality between the large and small probe designs. The memory technoK 
ogies considered included core, plated wire, bipolar semiconductor, and 
MOS semiconductor. 

In general, magnetic memories (core and plated wire) are not 
optimum for small capacity applications such as the 512 and 4096 bit 
memories required by the probes, A magnetic memory in this size range 
(590 bits) was recently investigated for another Hughes space program, and 
the results of the investigation support the above conclusion. Table 4-19 
contains the data from manufacturers' quotes on the 590 bit space qualified 
magnetic memory received during that investigation. The manufacturers 
indicated that the parameters would only vary a small amount with increases 
or decreases of a few times in the capacity, so these figures are felt to be 
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TABLE 4- 19. 590 BIT MAGNETIC MEMORY CHARACTERISTICS 


Memory Type 

Dimensions , 
cm 
(in) 

Mass 

(weight), 

kg 

Ub) 

Power , 
W 

Cost 

Plated wire 
(Manufac- 
turer A) 

14. 0x19.3x19.0 
(5.5 X 7.6 X 0. 75) 

0. 45 
(1.0) 

0. 75 

$250,000 
nonrecurring 
$20, 000 per 
unit 

Plated wire 
(Manufac- 
turer B) 

14. 7 X 20. 3 X 3. 3 
(5. 8 X 8 X 1.3) 

0. 90 
(2.0) 

0. 35 

$100,000 
nonrecurring 
$5,000 per 
unit (without 
sufficient 
quality for 
Pioneer Venus) 

Core 

(Manufac- 
turer C) 

10. 3 X 15. 2 X 1. 3 
(4 X 6 X 0. 5) 

0. 22 
(0.5) 

0. 5 

$100,000 
nonrecurring 
$5., 000 per unit 


a relatively accurate representation of magnetic memory parameters for 
the probe application. Because of their excessive size, mass, and cost, 
these memory types were not selected for the probe data memory. 

Data on a variety of semiconductor random access memories (RAMs) 
were also collected. The objective of the investigation was to identify a 
rnemory device capable of meeting the needs of the probe data memories, 
and to generate data for determining probe characteristics based upon the 
use of this device. However, the state of the art in semiconductor memories 
is advancing so rapidly that in all probability, by the time of the Pioneer 
Yenus final design, better devices v^ill be available for spaceborne use 
than there are at the present time. The characteristics of several currently 
available RAMs are given in Table 4-20, 

Upon examining the characteristics of the available semiconductor 
memories, it was observed that memories containing more bits do not 
necessarily dissipate more power than memories with fewer bits. This is 
due to the fact that the maximum heat that can be dissipated in an integrated 
circuit package tends to be a constant limiting factor upon designs. Thus, 
the designer does not necessarily pay a penalty of higher power for choosing 
a memory device having more bits. Therefore, in order to utilize common 
devices, it would be preferable to use memory chips of 1024 or 2048 bits 
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TABLE 4-20. CHARACTERISTICS OF SOME SEMICONDUCTOR 
RANDOM ACCESS MEMORIES- 


ORGANIZATION 

MANUFACTURER 

PART NO, 

TECH. 

STATIC OR 
DYNAMIC 

POWER 

(nw) 

SUPPLY 

VOLTAGES 

dt/ttl 

COMPATIBLE 

SPACE 

QUALIFIED 

16 X 1 “ 16 

I 

Texas Instruments 

SN5481 

Bipolar 

Static 

300 

+5V 

Yes 

No 

16 X 4 = 64 

Advanced Micro 
Computer Microtech. 

AM31L01 

CM2106 

Bipolar 

Static 

135 

+5V 

Yes 

Yes 

64 X 2 ^ 128 

Collins Radio 

CRC 4002 

MOS-P 

Static 

150 

+12V 

Yes 

No 

128 X 1 » 128 

Advanced Mem Sys 

AMS 1503 

Bipolar 

Static 

400 

+5V 

Yes 

No 

128 X 2 - 256 

Motorola 

MCM 4257 

Bipolar 

Static 

500 

+5V 

Yes 

No 

64 X 4 * 256 

Collins Radio 

CRC 4003 

MOS-P 

Static 

300 

+12V 

Yes 

No 

256 X 1 - 256 

Intel 

IIOIAI 

MOS-P 

Static 

200,400 

+5V, -9V 

Yes 

No 

256 X 1 = 256 

Computer 

Mlcrotechoology 

CM2 150 

Bipolar 

Static 

300 

+5V 

Yes 

Yes 

256 X 1 = 256 

Solid State Scientific 

SCL5553 

C-MOS 

Static 

.060 

+12V 

Yes 

No 

1,024 X 1 = 1,024 

Electronic Arrays 

EA1502 

MOS-N 

Dynamic 

165 

-12V, +12V 

Yes 

No 

1,024 X 1 = 1,024 

Intersil 

1M5508 

Bipolar 

Statis 

100 

+5V 

Yes 

No 

1,024 X 1 = 1,024 

Mostek 

MK4006P 

PMOS 

Dynamic 

450,50 

+5V, -12V 


No 

1,024 X 1 = 1,024 

Fairchild 

93415 

Bipolar 

Static 

500 

+5V 

Yes 

No 

1,024 X 1 = 1,024 

Raytheon 

R5500 

Bipolar 

Static 

400 

+5V 

Yes 

No 

1,024 X 1 - 1,024 

TI 

SN54S204 

11 

Static 

500 

+5V 

Yes 

No 

1,024 X 2 = 2,048 

TI 

TMS4020 

P-MOS 

Dynamic 

320 

+2V, -16V 

Yes 

No 

2,048 X 1 = 2,048 

Advanced Memory Systems 

AMS6003 

MOS 

Dynamic 

164 

+5, +8, 
-15V 

Except 

Clock 

No 


*The memories described do not represent A complete listing of available devices. Emphasis was placed upon devices in the size range 
appropriate for the probe data memory, Where two values of power are given for a device, the lower value represents a "standby power" 
sufficient to maintain the data In memory, while the higher value is an "operating power" necessary to load or interrogate the memory. 
Memories are listed as "space qualified" if qualification procedures are now complete or under way and are expected to be complete before 
the conclusion of the present Pioneer Venus study contract. Even "space qualified" Tnemortes may require additional testing to verify 
survival of the probe 500 g deceleration, however. 




in the design of both of the probe data memories if a qualified device were 
available. Even though the small probe requires only 51Z bits, using this 
approach to commonality is more attractive than using 256 or 512 bit 
memory chips in the large probe. 

However, since space qualified 1024 or 2048 bit devices are not 
presently available, the memory chosen for use on both probes is the 
Computer Microtechnology CM2150, a 256 bit bipolar device because it is 
being qualified by Hughes for another space program. Thus, the qualifica- 
tion cost associated with use of this memory device on Pioneer Venus will 
be limited to the cost of verifying survival of the Venus entry deceleration. 

On the other hand, since 16 CM2 150 devices are required to build 
the large probe memory, and since the power dissipation of the device is 
also relatively high, it still might be preferable, in spite of qualification 
cost saving, to consider use of an alternate device. Several lower power 
and higher capacity devices such as the Solid State Scientific SCL 5553, 
a 256 bit CMOS memory dissipating only 60 microwatts or the Intersil 
IM 5508, a 1024 bit bipolar device with one-twelfth the power dissipation 
per bit of the CM2 150, will continue to be monitored in the event that one 
should become qualified. 

Probe Stored Data Playback Techniques 


This subsection reports the results of a study upon the probe data 
handling subsystem of employing a single, uninterrupted memory "dump" 
to return the data stored during entry deceleration as opposed to inter- 
leaving it with real time science data transmission; the initial report of this 
study may be found in Reference 4-4. 

It was found that, contrary to early expectations, playing back the 
probe stored data in a single "burst," which would interrupt the transmis- 
sion of real time data, did not allow a power reduction in die probes. 
Because no advantages of a burst playback were found, and because of the 
additional complexity of this technique, the approach of playing back the 
stored data interleaved with real time data is preferred. 

Hughes original design employed interleaved playback, as recom- 
mended by the science definition study. However, the possibility of a power 
saving was thought to exist if a dump approach were used, in that the data 
memory can be powered down after the completion of stored data transmis- 
sion; a dump might allow this to be accomplished sooner. The investigation 
was conducted using current estimates of probe descent profiles and the 
science data rate requirements given in the preliminary science definition 
report. Both interleaved and burst playback were found to be feasible. 
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The interleaved data playback was chosen; following are the 
considerations which led to this decision: 

1) The use of "dump” playback would require an additional data 
format, which would complicate the data handling subsystem 
as well as ground processing. 

2) The use of a data dump would not, in fact, allow the probe 
data memory to be powered down appreciably sooner than would 
be the case with interleaved playback in a properly planned 
format. If a memory dump were conducted during the early 
phases of the descent, capability would be required to either 
store data during the dump, or to interrupt the memory dump 
frequently for long periods of time to accommodate real time 
data transmission. The store during dump capability would 
complicate the probe data handling subsystem appreciably and 
would require that the memory remain powered until the data 
stored during the dump were played back. The data interrupts 
required by this approach would be so frequent and so lengthy 
as to essentially amount to interleaved playback. If the memory 
dump were delayed until just before parachute release, it might 
be possible to complete an entire memory dump playback between 
required sample points of real time data. However, present 
figures for data rate and descent rate indicate that this would 

not be possible without increasing the transmission bit rate. 
Furthermore, delaying the memory playback until this time 
would require that the data memory remain powered longer 
than would be the case if interleaved playback were used. 

3) Interleaving of stored and real time data has the disadvantage 
that words in the format, used for data playback, would contain 
redundant information after the memory had been played back 
once. Since the percentage of bandwidth used for playback is 
small, this is not a serious disadvantage. The present figures 
indicate that a 147 word format, including six words of stored 
data playback, would accommodate all large probe experiments. 
This format, at 256 bps would allow two complete playbacks 
of the stored data in less than seven minutes. After that time, 
the memory could be powered down. If the playback were con- 
ducted as slowly as possible, while still achieving two complete 
playbacks of data before the probe reached an altitude of 20 km, 
less than 3 percent of the data format would be devoted to stored 
data playback in the large probe. In the small probe, because 
of the more rapid descent, the stored data playback would occupy 
approximately 5 percent of the data bandwidth. In both the large 
and the small probes, it is possible to play back the stored data 
interleaved with real time data without requiring a major per- 
centage of the data bandwidth. Two data playbacks could still 
be completed early enough in the descent to allow important 
power savings by powering down the data memory. 
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Probe Multiple Data Formats 

This subsection reports on an investigation of the impact upon the 
probe command and data handling subsystems of providing two or more data 
formats for use during different phases of the probe entry and descent ; the 
initial report of the study may be found in Reference 4-4. 

The additional coat to the probes of providing more than one data 
format is not expected to be appreciable. This results from the fact that the 
probe data formatting is controlled with read only memory (ROM) elements. 
Depending upon the complexity of the additional data formats, which will not 
be fully defined until system design is completed, it is expected that the cost 
will be limited to providing the additional command outputs necessary to 
change formats plus some additional ground processing complexity. It is 
felt that the overall system advantage to be gained by providing multiple 
formats (i.e. , to meet science data return requirements without having to 
add increased rf power amplification) is worth the possible increase in 
complexity. 

An investigation was made to determine the modifications required 
in the probe data handling subsystem to accommodate more than one data 
transmission format. In the initial design for the probes, ROM devices 
were used in order to accommodate a relatively complex data format and 
to allow changes to the format until as late in the program as possible. 

Since the optimum way to design for multiple data formats is also by use 
of ROM devices, the existing implementation allows them to be accommodated 
with a minimum of impact on the design. 

During the initial design, a survey of ROM devices was conducted. 

The Harris HPROM 1024, a 1024 bit bipolar TTL compatible device, was 
selected. A combination of these devices was used to implement the design; 
this may be adequate to control more than one format, depending upon the 
total number of data inputs, the sampling requirements of each, and the 
method of implementing the programming of data formats. The most cost 
effective implementation cannot, be determined until final definition of the 
data formats is complete. However, it is felt that the flexibility offered by- 
the use of ROMs will allow provision for multiple data formats without sig- 
nificant impact upon the data handling subsystem design. Command subsys- 
tem outputs are, of course, needed to change the formats. But sufficient 
spare outputs are presently available to accommodate this without change to 
the command subsystem design. Additional formats will, to some extent, 
increase the complexity of ground processing equipment and/or software. 

The savings afforded to the overall system design by the use of 
multiple formats appear to justify the slight increase in complexity to the 
data handling subsystem. The Harris memory is preferred, in spite of its 
relatively high power dissipation, because it is presently being qualified for 
space programs. It is possible that an even better device may be qualified 
by the time of the final probe design; but a change of memory should not affect 
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FIGURE 4-9. SINGLE DATA RATE SYSTEM 



FIGURE 4-10. MULTIPLE DATA RATES IN BINARY RATIOS 
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FIGURE4-11. MULTIPLE DATA RATES IN NONBINARY RATIOS 
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the result of this study* The only advantages of using another memory 
would be a reduction in memory power dissipation. In the present probe 
design, the power dissipation of the ROM has been reduced to a very low 
average value by switching power to the ROM only when it is to be interro- 
gated. Therefore, the Harris ROM can be used with no appreciable power 
or weight penalty, and additional probe data formats can be generated with- 
out appreciable changes to the initial design. 

Probe Multiple Data Rates 

Because of the attenuation of the Venusian atmosphere, power in the 
communications subsystem can be minimized by transmitting data more 
slowly at lower altitudes, and a rate reduction appears feasible from a 
systems standpoint. The subsection reports a study to determine the weight 
and power impact on the probe command and data handling subsystems from 
the inclusion of more than a single data rate. As expected, the weight and 
power increases were small. The use of multiple data transmission rates, 
including certain rates which are not related by integral binary ratios, does 
not significantly complicate the probe electronics. Details of this study were 
initially reported in Reference 4-5, 

To determine the design impact of providing multiple data rates, cir- 
cuit designs of the relevant portions of the command and data handling sub- 
systems were prepared. The designs incorporated provisions for various 
data rates and combinations of rates. Rates that are not related by integral 
power of two ratios were included. 

In the initial design, the data handling subsystem of the probe is 
operated from a single clock frequency. This single clock drives the timers, 
multiplexers, data formatter, convolutional coder, and all other elements of 
the data handling subsystem. It is gated and provided to the science instru- 
ments as a read clock. Thus, the probe data rate can be varied, without 
altering the data format, by simply varying the subsystem input clock rate. 
Furthermore, the mass, cost, and volume penalties in the command and 
data handling subsystems due to providing more than one data rate are 
entirely associated with the added circuitry needed to generate and select 
the required clock frequencies- 

A common crystal oscillator and countdown chain provides clock and 
timing pulses for the entire command and data handling subsystem of the 
probe. If only a single data rate were required, this countdown chain would 
be implemented as a series of divide-by-two stages as shown in Figure 4-9. 
With the addition of gating for clock selection, as shown in Figure 4-10, this 
same arrangement of counters can provide multiple data rates as long as the 
required rates are related by ratios that are integral powers of two. Rates 
between the integral powers of two can conveniently be obtained by use of a 
divide-by-three stage (or a divide -by -five, -seven, . . . ) followed by any 
additional stages necessary to provide data subsystem clock rates; this 
method is illustrated in Figure 4-11. 
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Considering the single data rate case (Figure 4-9) as a basis for 
comparison, the increments to parts count, mass, and power were computed 
for: 1) systems providing two data rates related by an integral power of two 

ratio, 2) for a system providing two rates not related by an integral power 
of two, and 3) for a system providing up to four rates not related by powers 
of two! The estimates are based upon the use of low power transistor/ 
transistor logic (TTL) circuits, and represent realistic increments to the 
subsystem design. 

Table 4-21 presents the results of the study- The quantity of circuitry 
added to provide a multiple data rate capability in the probes is very small, 
even if rates differing by ratios other than integral powers of two are chosen. 
The mass, parts, and power increases in no case exceeded 4 percent. 
Therefore, the conclusion is that multiple data rates should be used in the 
probes if their use will significantly reduce the mass or power of the other 
probe subsystems. This conclusion supports the initial decision to provide 
for a reduction of the data rate at low altitudes to one -half its value at 
higher elevations. 

When more than one data rate is to be used, command outputs must be 
utilized to select the desired rate. However, sufficient spare outputs are 
available to accommodate this data rate selection. 


TABLE 4-21. IMPACT OF MULTIPLE DATA RATES 


Multiple Data Rate 
Alternatives 

Mass 

(weight) 

Increase 

Power, 

Increase, 

mW 

Com- 

ponent 

Increase 

ICs 


(lb) 

Choice of two rates related by 

0.014 

(0. 03) 

10 

2 

binary ratio 





Choice of two rates related by 

0. 023 

(0. 05) 

20 

3 

l;2^/3 ratio 





Choice of up to four rates 

0.045 

(0. 10) 

45 

6 

related by binary and by 





l:2^/3 ratios 

1 
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4.3 SURVEY OF AVAILABLE SUBSYSTEM HARDWARE 

Minimum cost and risk should result from using existing, proven 
designs and hardware for the command and data handling subsystems. 
Accordingly, known suppliers of space command and data handling equip- 
ment have been solicited to determine the availability of equipment which 
could meet program requirements with no more than minor modifications 
to existing designs. 

_ Preliminary specifications of requirements on the command and data 
handling subsystems for the Pioneer Venus spacecraft and probes were pre- 
pared as a basis for solicitation of data from vendors. As much as possible, 
parameters were specified loosely or not defined in order to enable existing ' 
hardware to meet the requirements. During December 1972, 12 companies 
with related experience were invited to submit technical and rough order of 
magnitude cost data. Six companies responded with data: one on command 

equipment only, one on data handling equipment only, and four on both. In 
addition, some of these and other companies provided verbal information in 
response to our telephone or in person contacts. 

In addition to outside sources, command and data handling equipment 
designed by Hughes was reviewed for applicability to Pioneer Venus. 

Spacecraft Command Subsystem 

Analysis of the available command equipments has led to a buy decis- 
ion for the command demodulator and a make decision for the decoding 
equipment using OSO-I designs. 

Communications link considerations have dictated the desirability of 
using a phase- shift-keyed (PSK) demodulator which provides a theoretical 
3 dB improvement over the more commonly used frequency- shift-keyed 
(FSK) demodulator, Spaceborne PSK demodulators with characteristics 
generally suitable for Pioneer Venus are under development by several 
companies. For example, two such demodulators are under development 
by RCA and Motorola for the Viking Lander and the Viking Orbiter, respec- 
tively. Hughes, on the other hand, does not have a PSK demodulator with 
characteristics as suitable for Pioneer Venus as the above designs. The 
demodulator, therefore, is recommended to be a buy item. 

None of the decoders for which vendor data was obtained appeared to 
be very attractive for the spacecraft decoding application. All vendors have 
to modify existing designs or perform a new design. Analysis of the limited 
data received indicates that, of the vendors who responded. Radiation, SCI 
Systems, and Texas Instruments have designs which could be modified to 
provide an acceptable combination of characteristics. 

Review of several Hughes decoder designs indicates that the command 
decoding system for the OSO-I program is not only the best choice among 
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Hughes designs, but also has a number of distinctly advantageous features. 

Among these are: 

1) The command output module, that interfaces with science 
instruments and spacecraft subsystems, has been carefully 
developed over a decade and represents an optimum interface 
from the points of view of noise tolerance and inadvertent com- 
mand execution due to faulty equipment. In addition, its use 
further enables use of some other subsystems fromOSO-I, 

Hughes' most current science exploration satellite, with little 
or no modification. Also, it is an interface with which Hughes' 
science integration and spacecraft development engineers are 
intimately familiar. 

2) The OSO-I command subsystem is modular, thus providing 
flexibility to accommodate larger or smaller command require- 
ments than in OSO-I by simply adding or deleting command out- 
put modules. This feature has proven to be very desirable on 
several programs using a similar modular concept. It permits 
completion of command subsystem hardware design and fabrica- 
tion before completion of a final specification on total command 
requirements, which frequently vary during a spacecraft 
development phase. 

3) The distributed nature of the OSO-I subsystem, in which the 
command output modules (remote decoders) can be located close 
to user subsystems and science instruments, results in a much 
simpler harness management job than when a centralized decod- 
ing subsystem is used. This is because only one signal and one 
power line (plus ground) connect each of two redundant central 
decoders with each command output module, each of which have 
an output capability of 64 pulse commands and four serial mag- 
nitude commands. This may also provide a weight reduction, 
since the weight of the additional electronic parts used in the 
modular subsystem are more than compensated by the reduction 
in wire weight of the command output lines when the average dis- 
tance between central decoders and user subsystems exceeds 

1 m. 

4) The OSO-I command output module (remote decoder) can be used 
without modification for Pioneer Venus. 

5) The OSO-I command output module uses custom MOS-LSI devices 
to mechanize most of its functions, which permits inclusion of 
several desirable features while minimizing weight. The Hughes 
MOS-LSI devices are built using a space process that can tolerate 
a radiation dose of 10^ rads (Si), which is greater than the anti- 
cipated requirement during the longest orbiter mission. 
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For these reasons, the existing OSO-I command output module is 
recommended for the Pioneer Venus spacecraft. 

A new central decoder design is recommended; the unit will be 
designed to provide compatible interfaces with the PSK demodulator to be 
selected as well as with the existing command output module design. Much 
of the circuitry would, be the same or similar to that in the OSO-I central 
decoder. In addition, the receiver reverse switching function and the com- 
mand memory function would be included in this unit. 

Spacecraft Data Handling Subsy stem 

Analysis of the available data handling equipments has led to the 
following decisions: 1) a make decision for the data input module and PCM 

encoder unit, both of which use unmodified OSO-I designs; Z) a buy decision 
for an available, or slightly modified, magnetic core data storage unit 
(orbiter spacecraft only); and 3) a make decision for a new telemetry pro- 
cessor which provides a compatible interface with each of these existing 
designs. 


As was the case with command decoders, no vendor of data handling 
equipment who supplied information in response to Hughes request has an 
existing design, which is close to meeting the principal requirements for 
the Pioneer Venus spacecraft. While data received were somewhat inade- 
quate for a thorough assessment, it appears that each of the equipments was 
deficient in one or more respects. Some of these deficiencies are as follows 

1) Only one or two data modes (formats) are provided. As many 
as seven may be necessary for both the multiprobe spacecraft 
and the orbiter spacecraft, with simultaneous real time and 
stored formats required for the latter. 

2) Too few data inputs were provided. 

3) No serial digital data input capability (e. g. , radiation). 

4) Less than 8 bit encoding (e. g. , Texas Instruments and TRW), 

5) In one case (SCI systems) a new design was proposed with no 
reference to a specific related existing design. 

Of Hughes telemetry equipment designs, the OSO-I design is most 
applicable to Pioneer Venus. The OSO-I telemetry and data handling sub- 
system has two units that meet all Pioneer Venus requirements. These are 
the data input module (remote multiplexer) and the PCM encoder unit. Some 
of the desirable features of these units are: 

• The data input module provides a data interface with science 
instruments and. spacecraft subsystems that accommodates 
analog, serial digital, and discrete bilevel data in several 
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pin-programmable mixes depending on specific user-subsystem 
requirements. 

• Any data input line can be shorted to a voltage between -50 and 
+ 50 V with no damage or degradation of other channels. This 
protects hardware from possible damage during system test, 
eliminating a potential schedule risk. 

• The OSO-I telemetry subsystem is modular, thus providing the 
same flexibility to accommodate subsystem changes as cited 
above for the OSO-I command subsystem. 

• The distributed nature of the OSO-I subsystem, with data input 
modules located near user subsystems, also results in a much 
simpler harness management job and a potential weight savings; 
the advantages are similar to those cited for the command sub- 
system above. 

• Each data input can be addressed in a random access manner. 
Data formats are, therefore, completely under the control of a 
format generator in the telemetry processor. Since data trans- 
fer between the data input module and the PCM encoder and 
format generator is by means of high speed data bursts, simul- 
taneous stored, and real time formats can be easily implemented. 

• Both units can accommodate an interrogate channel rate of dc to 
3Z00 channels /second; this can easily meet the needs of Pioneer 
Venus. The channel and bit rates are completely controlled by 
the format generator. 

• Like the command output module, the data input module uses 
modern MOS-LSI technology to achieve its functional capability 
with minimum weight and maximum reliability. 

• The PCM encoder converts analog data to the required 8 bit 
resolution. Accuracy is enhanced by differentially encoding 
each data point relative to the analog signal ground in the user 
subsystem. The encoder also feeds a precision current via the 
data input module to a user's resistive transducer (such as a 
thermistor temperature sensor), while the latter is addressed. 
This current is used as a stimulus to produce a voltage which 
can be measured. 

The OSO-I data input module and PCM encoder are therefore recom- 
mended for the spacecraft data handling subsystem, since they appear to be 
highly suitable for the Pioneer Venus spacecraft application. Furthermore, 
they provide interfaces with science instruments and spacecraft subsystems 
with which Hughes' science integration and spacecraft development engineers 
are intimately familiar and which permit the use of a number of existing 
interface circuit designs in the user subsystems. 
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The orbiter data storage hardware trade study (see subsection 4. 2) 
recommended the use of a magnetic core memory for the data storage appli- 
cation. Several vendors have developed^ or are developing^ spaceborne 
core memories having capacities in the range required for Pioneer Venus; 
good potential exists for one of these memories being usable as designed or 
with minor modifications. Among the candidate vendors for core memories 
are Electronic Memories (Viking Lander, SEMS-8 or SEMS-9 designs), 

SCI Electronics, Spacetac, Standard Electrik Lorenz (Helios design), and 
Fabri-Tek. If cost is comparable, a plated wire memory would be accept- 
able; possible vendors of such memories are SCI Electronics, Motorola, 
Honeywell, and Sperry Rand- As of this writing, these vendors have been 
requested to provide a technical proposal and cost estimates for a memory 
meeting the orbiter data storage requirements. 

A telemetry processor is required to perform the format generation, 
timing, convolutional encoding, and modulation functions; its interfaces must 
be compatible with the selected data storage unit, the PCM encoder, the 
data input module and the rf subsystem. This unit would have to be of new 
design^ Many of the circuits for the format generator and timer, however, 
are available from the OSO-I format generator and spacecraft clock units. 
Design by Hughes is recommended because of the applicability of this OSO-I 
circuitry and because of the need for close interface coordination with 
designers of the other units, particularly the PCM encoder and data input 
module- 

Probe Command and Data Handling Subsystem 

No existing command and data handling hardware has been found that 
has been designed to meet the 500 g peak deceleration. This would dictate 
a new or modified packaging design independent of whether circuit designs 
are of existing or new design- The probe equipment, unlike the spacecraft 
equipment, is also subject to severe volumetric and form factor constraints. 
Hughes feels that this constraint makes mandatory a new packaging design 
by product design engineers working in close coordination with probe inte- 
gration personnel. While existing or modifications of. existing circuits may 
be used, this constraint also dictates a circuit design tailored to the probe 
requirements. Since an off-the-shelf design that is adequate is likely to 
have features and circuitry greater than required, its volume and weight 
are also likely to be excessive. 

For these reasons, Hughes recommends an in-house design of the 
probe command and data handling subsystems. While a new packaging 
design using established techniques is required, a number of circuits froni 
OSO-I are applicable with some modification. Electronic parts are mostly 
of the same types already space qualified and planned for use on the Pioneer 
Venus spacecraft. 
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Pyrotechnic Control 

While the functional complexity of the pyrotechnic control circuitry 
(squib drivers) is much simpler than the remainder of the spacecraft and 
probe command and data handling subsystems, the irreversible nature of 
squib firings necessitates a design which is both highly reliable and very 
insensitive to input signal and power line noise. Such circuitry has been 
successfully used on ail Hughes spacecraft* In particular, the OSO-I squib 
driving circuitry has been designed to be compatible with the command 
interface recommended for Pioneer Venus* However, the requirement to 
fire three squibs simultaneously in the Pioneer Venus space vehicles neces- 
sitates use of a higher power output transistor* The same circuit will be 
used for spacecraft and probe applications. 


4.4 PYROTECHNIC TRADE STUDY 

Actuation of mechanical components such as separation nuts is 
required on the orbiter, probe bus, and probes* Pyrotechnic mechanics 
will be used to activate or trigger these components. 

A tradeoff has been made between alternate designs in order to deter- 
mine pyrotechnic configurations. The three basic elements of a pyrotechnic 
subsystem analyzed were: 

1) Initiator characteristics, i. e. , explosive and nonexplosive 
types, 

2) A means for providing a highly reliable method of power switch- 
ing to provide electrical power to the specific initiation selected. 

3) A power source capable of providing a large current to an 
initiator for a short time period* 

Initiator Characteristics 


Two basic types of initiators are used. A bridge wire type of initiator 
(squib) ignites a small amount of propellant and generates gas at high pres- 
sure* This is generally used to actuate separation nuts, pin pullers, experi- 
ment breakoff hats, valves, orbit insertion motor igniters, and other 
functions. 

The other types of initiator is a nonexpLosive hot wire initiator which 
ruptures a hot wire element that pulls a pin. This type is used to disengage 
electrical connectors, jettison windows on the large probe, and deploy 
mechanisms on the small probes. 
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Bridgewire Types 


Actuation time following application of current to squibs is not 
critical to most users. A 50 to 100 ms firing pulse is normally applied to 
guarantee firing, although most squibs in less than 5 ms. However, separa- 
tion of the small probes from the probe bus by means of three separation 
nuts must be timed very accurately. This requires an accurate determination 
of the delay time to properly time the firing pulse. It also requires a high 
degree of simultaneity between the three separation nuts. Separation of the 
large probe from the probe bus and parachute and aeroshell release from 
the large pressure vessel also require good simultaneity. Because release 
from the large pressure vessel also require good simultaneity. Because of 
these timing requirements, the power switches (squib drivers) that deliver 
the firing current to the squibs must also operate simultaneously. 

During firing the bridgewire initiator cartridge contains ionized gases 
that can provide a low resistance path from pin to pin and pin to case. Pre- 
cise quantitative data are not available; therefore, it must be assumed that 
during the nominal 50 ms firing pulse each squib can present a hard short 
circuit to the squib driver. This presents potential problems that will be 
discussed below. 


Most squibs have a very large postfire pin to pin and pin to case 
resistance after combustion has been completed. However, occasionally 
expended squibs have a relatively low postfiring resistance of approximately 
50 ohms. This makes it mandatory that the squib be disconnected from the 
power source after the firing sequence is completed in order to remove a 
potential parisitic load. 


The Single Bridgewire Apollo Standard Initiator (SBASI) has been 
selected for Pioneer Venus. The key performance parameters are; 


• All fire 


3. 5 A with 0. 999 reliability over 
-260'= to +300“F 


• No fire 


1 A / 1 W for 5 min 


• Bridgewire resistance 0.95 to 1. 15 ohms 

• Functioning time Approximately 2 ms to reach peak 

pressure at recommended firing 
current of 5 A 


Hot Wire Initiators 


Hotwire initiators are miniature, nonexplosive pin pullers. They 
have a wire element wound on helical grooves of a nonconductive , axially 
split spool that bears against a spring loaded plunger. The wire element 
has a short, reduced diameter section that offers local, increased electrical 
resistance. When the required current (3. 5 A minimum) is passed through 
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the wire, the reduced section heats rapidly to a temperature where the 
tensile strength is reduced to the point of rapture. The remaining wire 
unwinds and springs outward from the spool, permitting the spool halves to 
be separated by the wedging action of the spring loaded plunger. The plunger 
continues to be driven by the spring force, withdrawing the exposed end into 
the initiator housing. 

Electrical characteristics of the wire element are similar to squib 
bridgewires. They have a nominal resistance of 1 ohm and will fire within 
1 1 ms at 4, 5 A. No fire rating is 0. 5 A for 5 min. 

Squib Drivers 


General Squib Driver Requirements 

The squib drivers must supply a minimum of 5 A to each bridgewire 
or hot wire for approximately 5 ms. Since pyrotechnic actions are irreversi- 
ble, inadvertent actuation must be prevented by the following precautionary 
steps: 

1) An arm switch plus an execute switch must both be closed before 
firing current is delivered to a squib. 

Z) The execute command must follow the arm command within 
100 ms, otherwise the circuits are disarmed. 

The latter features means that all firing commands must be provided to the 
squib driver from command memory. A number of different driver configura- 
tions were investigated as described below. The most demanding require- 
ment is to fire six squibs (three primary and three backup) with a high degree 
of simultaneity. Therefore, this will serve as a common point of reference 
in a tradeoff of four different configurations. 

Individual Squib Drivers (Configuration A) 

Figure 4-12 shows a configuration derived from OSO. Squibs lA and 
IB are redundant; the same is true of 2A and 2B and also 3A and 3B. The 
upper (arming) switches are common, but each squib has its own individual 
lower (execution) switch. Each execute switch has a series isolation resis- 
tor to prevent excessive battery current in case of squib or harness short. 

It also prevents shunting of current from the other squibs by the shorting 
squib and thus, insures good simultaneity. 

The probe bus, orbiter, and four probes have a total of 79 bridge- 
wires and hot wires. This configuration would meet all their requirements 
satisfactorily, but it would require a very large number of power transistors. 
This, in turn, would result in a heavy and large pyrotechnic control unit 
(PCU). 
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FIGURE 4-13. SQUIB DRIVER CONFIGURATION B 
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FIGURE 4-14, SQUIB DRIVER CONFIGURATION C 
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Squib Driver Firing Series /Parallel Network (Configuration B) 

Figure 4-13 shows a configuration that was successfully utilized on 
Surveyor to actuate three pyrotechnic devices simultaneously. The redundant 
upper switch provides current limiting in the event of squib shorts. This 
switch pair is common to all squib networks. Each squib network is actuated 
by one common execution switch. Squibs lA and IB are redundant and acti- 
vation of either one will successfully perform the required function. Squibs 
2A and 2B, 3A and 3B provide redundancy in the same way. The 2 ohm 
resistor provides a shunt bypass to compensate for open failures. 

The most attractive feature of Figure 4-13 is that one power switch 
fires a large number of squibs. However, it does not have execution switch 
redundancy and a short during firing in any of the squibs could result in poor 
simultaneity. 

Capacitor Discharge Squib Driver (Configuration C) 

Figure 4-14 shows a configuration that has been used on Mariner 
spacecraft. It utilizes a large capacitor that slowly charges through a series 
resistor and arm switch. The squibs are fired by an execution pulse that 
discharges the capacitor into the squibs and isolation resistors. The 
advantages of this configuration are: 

1) Low battery current during capacitor charging 

2) Good simultaneity due to high initial peak currents 

3) Low number of squib drive switches 

The chief disadvantage is that large capacitors are required. Rapid sequential 
squib firing {such as large probe chute deployment, in flight disconnect, and 
aeroshell jettison) requires a dedicated capacitor bank for each individual 
function because there is not adequate time to recharge one capacitor bank. 

Simplified Multiple Squib Driver {Configuration D) 

Figure 4-15 represents a simplified version of Figure 4-12. Squibs 
are grouped together functionally through a common execute switch (through 
isolation resistors). This configuration reduces the overall number of 
required power transistors to a reasonable value and still meets all system 
requirements. This configuration has been selected as baseline. 

Redundancy Requirements 


Since many pyrotechnic functions are mission critical, it is important 
that suitable redundancy be provided. Yet, the number of initiators and 
squib drivers must be held to a reasonable number, especially in the probes 
where weight and volume are critical. Therefore, the following ground rules 
have been adopted. All mission critical events will have redundant arm and 
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FIGURE 4-16. BATTERY/PCU/BRIDGEWIRE CURRENT LEVELS 
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execute switches and redundant initiators. All experiments on the orbiter 
and probe bus will also have complete redundancy. Probe experiments will 
utilize a single bridgewire and a single driver unless experimenters specifi- 
cally request bridgewire redundancy. In the latter cases, redundant bridge- 
wires will be activated by single drivers. Probe jettisonable windows, 
window covers, and probe deployment mechanisms will also be activated by 
a single driver. 

Battery and Pyrotechnic Control Unit Current Requirements 

The minimum recommended current for each pyrotechnic initiator is 
5 A. This provides a very adequate safety margin and good simultaneity. 

The isolation resistance for each bridgewire in the PCU must be selected 
to provide a minimum current of 5 A (see Figure 4-16). The value of 
must be selected under the following conditions: 

1) Minimum battery voltage 

2) Maximum harness drop 

3) Maximum PCU arm and execute switch (combined) voltage drop 
of 4 V 

If two 21 cell nickel cadmium batteries are used, each cell will pro- 
vide approximately 1 . 05 V. Assuming a diode isolation drop of 1. 0 V, 21 V 
are provided to the PCU. must be 2.0 ohms for each bridgewire , to 
guarantee 5 A into each bridgewire. This results in a total battery current 
of 5 X 6 = 30 A. 

If bridgewire shorting occurs during squib ignition, and also assuming 
that the arm and execute voltage drops are reduced to a minimum value of 2 V, 
current through each individual execution switch can increase to a maximum 
of 8.2 A. Arming switch and battery current will increase, accordingly, to the 
maximum values shown in the left hand table of Figure 4-16. The battery and 
PCU must be able to operate at these current levels. 

The middle table of Figure 4-16 gives the same type of current data 
for an 18-cell nickel cadmium battery which provides 18 x 1.05 - 18.9 V to 
the PCU (Thor/Delta orbiter). This lower battery voltage results in lower 
isolation resistance values. This is undesirable because the maximum cur- 
rent values are higher when the bridgewires short. 

The right hand table of Figure 4-16 provides the same type of data for 
a 13 cell silver zinc battery (the present baseline probe and probe bus battery 
configuration). This battery provides a voltage of 13x1.3 = 16.9 V and requires 
an isolation resistance value of 1.2 ohms. This value provides less isolation 
between the individual initiators resulting in a larger maximum current when 
the bridgewires short. 

The above data indicate that a high battery voltage is desirable because 
it allows a high isolation resistor value. This, in turn, isolates the PCU and 
battery and minimizes the effect of bridgewire shorts. 
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TABLE 4-22. PROBE BUS INITIATOR AND DRIVER REQUIREMENTS 


F unction 

Number 

of 

Initiators 

Initiator 

Type 

Number 

of 

Drivers 

(Execute) 

Minimum 

Current 

per 

Driver, 

A 

' n 

Simultaneity 

Requirement, 

ms 

Mechanism 

Type 

Bicone antenna deploy*!' 

2) 

4.t* 

'P 

Bridgewire 






Pin puller 

Magnetometer boom 










deploy* 

2 


Bridgewire 


T *.ty 


15 


Pin puller 

Ultraviolet .boom 










deploy* 

2 


Bridgewire 






Pinpuller 

Large probe IFD=^ 

2 


Hot wire 


2 


5 


Connector 










disengage 

Large probe 









Separation 

s eparation* 

6 


Bridgewire 1 


2 


15 

4 

nuts (3) 

Small probe IFD (3)^ 

6 


Hot wire 


2 


15 


Connector 

i 









disengage 

Small probe 









Separation 

separation* (3) 

6 


Bridgewire 


2 


15 

2 

nuts (3) 

Ion mass spectrom- 




1 





Breakoff 

eter breakoff hat eject 

2 ] 


Bridgewire 






hat 

Neutral mass spectrom- 





^ n-* 


10 


Breakoff 

eter breakoff hat eject 

2 


Bridgewire 






hat 

Total 

30 


12*** 





^‘^Mission critical event 
'►'^Activated simultaneously 

arm switches also required 



Pyrotechnic Configurations 


Initiator and driver characteristics for the probe bus, orbiter, and 
the probes are summarized in this section, as are the safety requirements. 

Probe Bus 


Table 4-22 describes the probe bus pyrotechnic configuration. An 
execute command will release the bicone antenna, magnetometer boom and 
ultraviolet boom simultaneously, shortly after launch vehicle separation. 

The large probe in-flight disconnect (IFD) will break the electrical 
interface between the probe bus and the probe. The large probe will then be 
separated by activating three explosive nuts simultaneously with one com- 
mand. Three matched spring assemblies will then provide a small separa- 
tion force to the probe. 

The three small probe IFDs will break the electrical interfaces with 
the probe bus and the probes prior to physical separation. A rigid, semicir- 
cular arm with a V-cross section encircles each probe just aft of the aero- 
shell base diameter and preloads it against the bus structure. The arm is 
hinged at one end and clamped at the other end by a separation nut mounted 
on the probe bus. An execution command will actuate the separation nuts 
and a bolt ejector in each nut will provide sufficient impulse to the arm to 
force it to rotate at sufficient angular velocity and allow each probe to sep- 
arate cleanly. 

Prior to probe bus entry, one execute command will remove the break- 
off hats from the ion mass spectrometer and neutral mass spectrometer. 

The bridgewires and squib drivers are cross -strapped to provide 
full redundancy, 

Orbiter 


Table 4-23 describes the orbiter pyrotechnic configuration. The 
magnetometer boom will be deployed shortly after launch vehicle separation. 
The orbit insertion motor pyrogen ignitor is actuated through a safe and arm 
device. After orbit is achieved, the neutral mass spectrometer and ion 
mass spectrometer breakoff hats will be removed. 

The bridgewires and squib drivers are cross strapped to provide full 
redundancy. 

Large Probe 


Table 4-24 describes the large probe pyrotechnic requirements. 
The PCU is located in the pressure vessel, but most of the pyrotechnic 
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TABLE 4-23. ORBITER INITIATOR AND DRIVER REQUIREMENTS 


F unction 

Number 

of 

Initiators 

Initiator 

Type 

Number 

of 

Drivers 

(Execute) 

Minimum 

Current 

per 

Driver, 

A 

Simultaneity 

Requirement, 

‘ms 

Mechanism 

Type 

Magnetometer boom 
deploy* 

2 


Bridgewire 


2 


5 


Pin puller 

Orbit insertion motor^' 
igniter 

2 


Bridgewire 


2 


5 

. 

Pyrogen 

igniter 

Ion mass spectrom- 
eter breakoff hat eject 

2 


Bridgewire 






Breakoff 

hat 

Neutral mass spectrom- 
eter breakoff hat eject 

2 


Bridgewire 




10 


Breakoff 

hat 

Total 

8 


/ siu -A^ 


1 



^Mission critical event 
Activated simultaneously 
!{<«5 !:Two arm switches also required 



TABLE 4-Z4. LARGE PROBE INITIATOR AND DRIVER REQUIREMENTS 


F unction 

Number 

of 

Initiators 

Initiator 

Type 

Number 

of 

Drivers 

(Execute) 

Minimum 

Current 

per 

Driver, 

A 

Simultaneity 

Requirement, 

ms 

Mechanism 

Type 

Parachute deploy* 

2 

Bridgewire 

2 

5 


Mortar 

Pressure vessel/ 
deceleration mode 
disconnect 

2 

Bridgewire 

2 

5 


Cable 

cutter 

Aeroshell jettison* 

6 

Bridgewire 

2 

15 

4 

Separation 
nuts (3) 

Parachute jettison* 

6 

Bridgewire 

2 

15 

4 

Separation 
nuts (3) 

Mass spectrometer 
breakoff hat eject 

2 

Bridgewire 

1 

10 


Breakoff 

hat 

Mass spectrometer 
open/ close valves 

10 

Bridgewire 

10 

1 

5 


Valves 

1 

Window eject 

6 

Hot wire 

' 2 

15 


1 

Jettison 
spring (6) 

Totals 

34 


^ 


1 

i 



'i^Mission critical event 
*'^Two arm switches also required 
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TABLE 4-25. SMALL PROBE INITIATOR AND DRIVER REQUIREMENTS 


F unction 

Number 

of 

Initiators 

Initiator 

Type 

— 

Number 

of 

Drivers 

(Execute) 

Minimum 

Current 

per 

Driver, 

A 

Simultaneity 

Requirement, 

ms 

Mechanism 

Type 

Despin rockets* 

4 

Bridgewire 


2 


10 

4 

Igniter (2) 

Temperature probe 
deploy 

1 

Hot wire 






Pin puller 

Nephelometer window 
cover eject 

1 

Bridgewire 


'l 


► 

15 

■ 

Gas gener-- 
ator and 
cover 
release 

Pressure transducer 
inlet eject 

1 

1 

Bridgewire 



- 



Pin puller 

Totals 

7 









^Mission critical event 
-!'*Two arm switches also required 


devices are located outside the pressure vessel and must be activated 
through harness wires that pass through pressurized penetration feed- 
throughs. The arming switch also serves as a power on/off switch. This 
switch must turn off power to the PCU completely to prevent use of any bat- 
tery energy during the long 20 day cruise period. 

The first pyrotechnic event during the large probe descent is to eject 
the parachute by means of a mortar on the deceleration module. This event 
is initiated by a g-switch on the downward deceleration curve. All subse- 
quent pyrotechnic events are initiated by an internal timer. One sec after 
chute ejection, the pressure vessel/ deceleration module cable cutter is 
actuated to sever their electrical interconnections. Three sec after chute 
ejection, the aeroshell is jettisoned by activating three separation nuts 
simultaneously. Shortly after aeroshell separation, the neutral mass spec- 
tronneter breakoff hat will be ejected. Ten pyrotechnic valves will be 
opened and closed periodically during probe descent to gather and analyze 
atmospheric samples. Approximately 10 min after aeroshell jettison, the 
chute will be separated by activating three separation nuts. Experiment 
external windows will be jettisoned at a height of 40 km. 

Small Probe 


Table 4-25 describes the small probe pyrotechnic requirements. 
Once again, the arming switch must turn off all power to the PCU. All 
pyrotechnic devices are located outside the pressure vessel. Two despin 
rockets are activated on each small probe shortly before atmosphere entry. 
The nephelometer window is jettisoned, the temperature sensor is deployed, 
and the pressure transducer inlet plug is ejected by a single command 
shortly after atmosphere entry. 

Safety Requirements 

All harnesses between the PCU and initiators and associated con- 
nectors must be properly shielded to prevent premature ignition in high 
intensity rf fields. 

Electrical arming plugs must be provided for the four probes, probe 
bus, and orbiter to prevent injury to personnel by inadvertent ignition of a 
pyrotechnic device. These plugs interrupt power between the PCU and the 
initiators. They are installed during launch preparations. 

The orbit insertion motor requires a safe and arm device. In the 
safe position, a motor actuated mechanical barrier interrupts the explosive 
power train, disconnects the squibs from the PCU, and shorts the squib 
bridgewire terminals together. A safety pin provides positive mechanical 
lock that prevents motor movement from the safe to arm position. The pin 
is removed shortly before launch vehicle fairing installation. The igniter 
is armed just prior to liftoff by rotating the mechanical barrier and connect- 
ing the squib bridgewires to the PCU. Safing and arming after the safety pin 
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is removed must be controlled from the blockhouse through the umbilical 
connector. A visual safe and arm indication must be provided at the 
blockhouse. 

4.5 PROGRAMMABLE ON-BOARD DATA PROCESSOR 

In the search for mass reduction techniques on the Thor/Delta con- 
figuration, the alternative of using a centralized on-board data processor 
for performing major portions of the spacecraft command and data handling 
functions was investigated. This can be accomplished using a small gen- 
eral purpose computer on a time -shared basis. The studies show that this 
approach can yield up to a 26 percent reduction in the mass of the orbiter 
subsystem equipment, with attendant reductions in power and volume of up 
to 30 and 80 percent respectively; namely, these savings are up to 5. 7 kg 
(12. 6 lb). 5. 3 W, and 10,080 cm^ (615 in^). Estimates show that this imple- 
mentation can also result in a significant cost reduction of up to 16 percent, 
plus an improvement in reliability, for the command and data handling sub- 
system on the probe bus and orbiter spacecraft. In addition, an on-board 
processor provides various flexibility and adaptability features that are 
potentially very useful for optimizing spacecraft operation. 

Although a programmable on-board data processor offers these many 
attractive features, the study conclusion is that this approach is not recom- 
mended for the baseline design on this program. The rationale of this con- 
clusion is based primarily upon two of the established evaluation criteria: 

1) even though several small computers utilizing LSI technology have been 
developed, they have not yet been qualified for a spacecraft application and 
therefore cannot presently be considered to be available space hardware; 
and 2) being a departure from the more conventional, space proven design 
methods that employ special purpose electronics, this approach introduces 
a certain degree of risk that is not felt to be warranted on this program. 

As a footnote to this conclusion, it is expected that future space pro- 
grams will benefit considerably through use of these small general purpose 
computers for various on-board data handling and control functions. Cur- 
rently, the major problem with this approach is the lack of space qualified 
hardware. Eventually, some will be qualified and be available to use for 
these types of spaceborne applications, probably within the 1974/1975 time 
frame. 


The tradeoff study results are discussed in the following sections. 
However, these results do not reflect all of the spacecraft functions that 
were investigated. Initially, this study also considered use of the same cen- 
tralized on-board data processor to perform major portions of the space- 
craft attitude control electronics functions in addition to the command and 
data handling functions. It was established that the computational and con- 
trol capability of the central processor was sufficient to perform all three of 
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these spacecraft functions on a time -shared basis. Memory and processing 
speed estimates indicated that less than 4K words of program and scratch- 
pad memory were required and less than 50 percent of the machine's compu- 
tational capacity would be used in order to accommodate and execute the 
necessary software programs for all three functions. Although this addi- 
tional time-sharing of equipment would result in even greater mass, volume, 
and power savings, it was decided early in the study to concentrate only on 
the command and data handling functions in order to simplify the centralized 
equipment and analysis. Therefore, even though attitude control functions 
are considered to be a prime candidate for an on-board processor imple- 
mentation, this application is not included in the following tradeoff 
discussions. 

\ 

Centralized Command and Telemetry Data Handling Subsystem 

Figure 4-17 is a simplified block diagram showing the basic concepts 
of a centralized command and telemetry data handling subsystem that was 
considered for the Thor/Delta configuration of the probe bus and or biter 
spacecraft. The centralized subsystem consists of seven basic types of 
units divided into three functional equipment categories as follows; 

1) Time -shared central computer equipment 

a) Dual processor and I/O 

b) Dual memory 

2) Command equipment 

a) Dual command demodulator and configuration selector 

b) Remote decoders (six required) 

c) Dual pyro control unit 

3) Te lemetry equipment 

a) Dual PCM encoder 

b) Remote multiplexers (seven required) 

The time- shared data processor and I/O combination, plus the memory, 
form the central elements in this configuration. These elements are imple- 
mented by use of a small general purpose computer that performs a rela- 
tively large portion of the command and telemetry functions. Power 
supplies are not shown in Figure 4-17 in order to simplify the diagram. 

The shaded areas in the figure represent fully redundant, dual units. Any 
combination of these dual units can be used to perform the necessary 
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functions. Redundancy is achieved in the remote multiplexers and the 
remote decoders through the redundant assignment of data input and 
command output channels. The PCM encoder, remote multiplexers, 
and remote decoders are equipment items that were previously developed 
by Hughes for the OSO spacecraft program. For the sake of completeness 
some of the rf system interfacing equipment is also shown in Figure 4-17. 
This interfacing equipment is shown in dashed lines; namely, the command 
receiver, the antenna/ receiver transfer switch, the transmitter, and the 
associated antennas. 

Table 4-26 presents a summary of estimated mass, volume, and 
power characteristics of the centralized data subsystem that is depicted 
in Figure 4-17. The table includes estimates of the subsystem configur- 
ations for both the probe bus and orbiter spacecraft. 

For the purpose of this tradeoff study, the characteristics of the 
CDC-469 computer were assumed. The CDC-469 was selected for this 
tradeoff analysis primarily because of its small physical size, low power, 
and current production status. The basic characteristics of this computer, 
plus the characteristics of several other candidate computers, are shown 
in Table 4-28 in a later subsection. 

A comparison of the centralized subsystem characteristics versus 
separate, non- centralized command and data handling subsystems is 
shown in Table 4-27. This table summarizes and compares the mass, 
volume, and power characteristics of both of these subsystem design 
approaches for both the probe bus and orbiter spacecraft. In addition, 
the table shows a comparison of the dual central computer characteris- 
tics with the three particular units of the non-centralized subsystems 
that it replaces; namely, a dual central command decoder, a dual telem- 
etry processor, and a data storage unit. These tradeoff estimates 
indicate that significant reductions in mass, volume, and power are 
possible through the use of a centralized on-board processor, especially 
on the orbiter spacecraft where 393 kilobits of data storage is required. 

Reliability of the centralized subsystem is predicted to be 
somewhat better than for the separate, non-centralized subsystems 
approach. The reliability aspects of the hardware and software are 
discussed at length in a later subsection. 

The basic functions of each of the units shown in Figure 4-17 
are briefly described in the following paragraphs. 
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TABLE 4-26. CENTRALIZED COMMAND AND TELEMETRY DATA HANDLING SUBSYSTEM — 

CHARACTERISTICS SUMMARY 



Probe Bus 

Orbiter 



Mas s 
(weight) 

Volume 


Mass 

(weight) 

Volu 

me 

Power 

W 

Equipment 

Description 

kg 

(lb) 

3 

cm 

(in^) 

Power 

W 

kg 

(lb) 

3 

cm 

(in^) 

Dual central computer 

5. 1 

(11. 2) 

4, 590 

(280) 

5* 0 

7. 3 

(16. 0) 

5, 900 

(360) 

6. 0 

Dual command 
demodulator/ 
configuration selector 

2. 1 

( 4. 6) 

3,080 

(188) 

3. 0 

2. 1 

( 4. 6) 

3, 080 

(188) 

3.0 

Remote decoders (6) 

1. 8 

( 4.0) 

1, 720 

(105) 

0. 3 

1. 8 

( 4.0) 

1, 720 

(105) 

0. 3 

Dual pyro control unit 

1. 4 

( 3.0) 

1, 670 

(102) 

— 

0. 9 

( 2.0) 

1, 130 

( 69) 

— 

Dual PCM encoder 

2. 8 

( 6.3) 

3, 500 

(214) 

2. 6 

2. 8 

( 6.3) 

3, 500 

(214) 

2. 6 

Remote multiplexers 
(7) 

1.4 

( 3.0) 

970 

( 59) 

0. 3 

1. 4 

( 3.0) 

970 

( 59) 

0. 3 

Subsystem Totals 

14. 6 

(32. 1) 

15,530 

(948) 

11. 2 

16. 3 

(35. 9) 

16, 300 

(995) 

12. 2 


Note: Each of the dual units contain the necessary cross-strap switching and dual power supplies. 




TABLE 4-27. CENTRALIZED VERSUS NONCENTRALIZED SUBSYSTEMS - 

COMPARISON SUMMARY 



Probe Bus 

Orbiter 


Mass 








Equipment 

(weight) 

Volume 







3 


Power 



3 

-i 

Power 

Dea cription 

kg 

(lb) 

cm 

(in ) 

W 

hg 


cm 

(in) 

W 

Noncentralized Equip- 
ment Replaced by 
Central Computer 











Command subsystem: 











Dual central decoder 

4,3 

( 9.4) 

6.000 

( 366) 

3, 6 

4. 3 

( 9.4) 

6, 000 

( 366) 

3. 6 

Data handling 
subsystem: 











Dual telemetry 











processor 

3. 2 

( 7. 2) 

4,670 

( 285) 

5. 7 

3. 2 

( 7.2) 

4, 670 

( 285) 

5. 7 

Data storage unit 

— 


— 


— 

5. 5 

(12. 0) 

5,310 

( 324) 

2. 0 

Equipment 

Comparisons 











Equipment replaced by 
computer 

7. 5 

(16. 6) 

10, 670 

( 651) 

9. 3 


(28. 6) 

15, 980 

( 975) 

1 1. 3 

Dual central computer 

5. 1 

ill. 2) 

4. 590 

( 280) 

5, 0 

7. 3 


5, 900 

( 360) 

6. 0 

Noncentralized sub- 
systems, total 


(37. 5) 

21, 610 

(1319) 

15. 5 

22. 0 

(48.5) 

26, 380 

(1610) 

17. 5 

Centralized subsys- 
tem, total 


(32. 1) 

15, 530 

{ 948) 

11. 2 

16. 3 

(35. 9) 

16, 300 

( 995) 

12. 2 

Estimated computer 
savings 

2. 4 

( 5.4) 

6, 080 

( 371) 

' 4. 3 

5. 7 

(12. 6) 

10, 080 

( 615) 

5. 3 

Percent reduction 

14 


28 per- 


27 

26 


38 per- 


30 

of subsystem 

per- 


cent 


per- 

per- 


cent 


per- 


cent 




cent 

cent 




cent 


Notes: 

1) Each of the daal units contain the necessary cross -strap switching and dual power 
supplies. 

2) The dual central computer consists of two combined processor and special I/O modules, 
two power supplies, cross -strap switching, and memory modules as follows: two 4K 
modules for the probe bus and two 16 K modules (or four 8K modules) for the orbiter. 
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Time -Shared Central Computer 


The central computer equipment consists of two basic types of 
modules; namely, the combined processor and I/O modules and the memory 
modules. Two of each of these module types are used to provide complete 
dual redundancy. Either processor “I/O module can be operated with either 
or both memory modules. 

On the probe bus^ two 4 kilobit x 16 bit memory modules are used, 
while two 16 kilobit memory modules (or four 8 kilobit modules) are used 
on the orblter spacecraft to provide additional data storage capability. 
Software estimates indicate that less than Z kilobit words are required for 
the basic program storage, including program alterable scratchpad/data 
memory, for either spacecraft configuration. However, 4 kilobits of pro- 
gram memory are provided inorder to allow a reasonable margin for growth. 
The portions of memory that are reserved for program storage can be pro- 
tected, in 1024 word increments, by means of '’disable write" circuitry. 
This effectively allows the program to reside in a read only portion of 
memory to protect it from being altered inadvertently. However, this 
memory protection feature can be over-ridden, by means of a proper 
sequence of commands from the ground, if reloading or altering of the pro- 
gram is desired. 

The memory capacity of two 16 kilobit modules on the orbiter 
spacecraft can be allocated in the following manner: 

1) 4 kilobits of each module for program and scratchpad usage. 

2) 12 kilobits of each module for data storage. 

This provides a total data storage capability of 24, 576 words of 16 bits each 
for a total of 393,216 bits. 

The time -shared functions of the central computer are estimated to 
require less than 25 percent of the machines computational capacity. These 
functions are briefly described in later subsections. 

Reliability . A rigorous reliability analysis of the computer and 
centralized subsystem was not performed during this study. However, the 
reliability of this subsystem is expected to be somewhat better than that of 
the comparable, non-centralized command and data handling subsystems. 
This expected improvement is based upon a number of reasons that would 
tend to support such a prediction. Some of these are: 

1) The centralized subsystem contains less electronic component 
parts; this is evidenced by the lower mass. It is due to a high 
usage of LSI technology in the computer and also to the fact that 
the computer electronics are time -shared to a high degree for 
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performance of many functions. Conventional reliability analysis 
and prediction is highly influenced by the number (and types) of 
electronic components- 

2) The dual computer assembly has an additional level of cross - 
strapped redundancy that is not contained in a special purpose 
electronics configuration. That is, the memory modules are 
cross -strapped to operate with either of the processor -I/O 
modules; these two types of modules are used in lieu of a single, 
conventional special purpose electronics unit. Modularization 
of equipment, so as to provide additional cross -strapping points 
between redundant modules, tends to improve reliability 
apprec iably. 

3) Reliability (and performance) can be enhanced by the capability 
to reprogram the system while in space. This feature can allow 
more work-around methods and possibilities of compensating 
for a malfunction in the event a failure occurs (or of compensat- 
ing for slight deviations from predicted performance after some 
space operational experience has uncovered any incipient design 
deficiencies ). 

4) Several other spaceborne computer applications studies per- 
formed by Hughes have indicated that reliability is definitely 
enhanced by this type of a subsystem implementation (e. g. , 
studies related to the JPL Outer Planets Mission program and 
to military space programs). 

The contribution of software to the reliability of a centralized sub- 
system is a relatively intangible element. Good theoretical tools have not 
yet been developed for including software affects in the equations for 
analysis of system reliability. However, even though the tools for providing 
a high confidence measurenaent and prediction of software reliability are not 
available, the software can be assumed to be 100 percent reliable, especially 
when precautions are taken to compensate for this unknown factor. That is, 
if software has any affect on the reliability of a system, its influence can be 
cancelled out by providing the capability to dump the memory of the com- 
puter (to allow analysis on the ground) and to reload new programs into 
memory while the spacecraft is in space. 

Prediction of perfect, 100 percent software reliability can be rational- 
ized when the following type of argument is used. Namely, the system will 
perform exactly as directed by the software program. Any performance 
glitches must be attributed to one of the following reasons: 


1) Software design error ^ The possibility of design errors is not 
normally taken into consideration in conventional reliability 
analysis and prediction techniques. The detection and correction 
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of design errors is normally expected to be accomplished prior 
to launch^ since this is one of the objectives of a comprehensive 
spacecraft test program. If design errors remain undetected, 
the testing was evidently not sufficient; these incipient design 
deficiencies should not be attributed to erroneous reliability 
analysis and prediction. (Although, the reliability analysis 
procedures are really inadequate in that they cannot account for 
these eventualities. ) 

2) Hardware failure. 

3) Software program disturbance induced by a hardware ’’glitch" 
or failure. 

Using this type of rationale, no detrimental reliability affects can be 
attributed to software. System performance problems can only be attributed 
to inadequate testing or to hardware. It appears that software has no affect 
on reliability. 

Command Functions 

Four types of units are involved with the handling of spacecraft com- 
mands in this centralized subsystem. The functions of each of these types of 
equipment modules are briefly described below. 

Command Demodulator /Configuration Selector . Upon receipt of the 
receiver in-lock indication and subcarrier signals from the command 
receiver located in the rf subsystem, the proper command demodulator/ 
configuration selector unit is activated, by recognizing the proper address- 
able frequency, and it begins operation. The unit remains activated until 
loss of the subcarrier, at which time it is shut down- The real time uplink 
PSK subcarrier is received and demodulated into digital command data and 
clock signals. These incoming data and clock signals are then transmitted 
to the central computer for processing of the commands. 

In addition to its primary function of command demodulation, 
important equipment selection functions are also performed by this unit. 

It controls activation of the desired set of redundant computer modules as 
selected by the ground. This Is accomplished by means of several unique 
commands that are recognized and decoded by the configuration selector 
portion of the unit. As determined by these decoded commands, on/off 
control signals are generated to activate a particular processor -I/O module 
and memory module combination that is selected for operation- The execu- 
tion of these configuration commands is completely independent of, and 
cannot be affected by, the central computer itself. Once activated, the 
selected configuration of computer modules will remain in operation until 
changed by ground command. After the selected computer modules have 
been activated in this manner, the computer receives command instructions 
from the ground to activate the desired combination of all other redundant 
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units in the stibsystem. Upon receipt of these instructions, the computer 
subsequently issues specific commands that control the necessary on/off 
switching to activate the desired units^ This total configuration selection 
sequence allows the ground to have full control for selecting any combination 
of redundant units within the subsystem. 

Another important equipment selection function of the command 
demodulator /configuration selector unit is controlling the state of the 
antenna/ receiver transfer switch in the rf subsystem. This switch deter- 
mines the connection combination of the two omniantennas with the two 
command receivers. In the event the spacecraft has not received valid 
command data within a predetermined number of hours, a timer in this 
unit generates an antenna reverse pulse. When valid commands have been 
received, a polycode verification check by the central computer normally 
resets this timer in order to maintain the current antenna/receiver connec- 
tions. The timer can also be reset by real-time or stored commands issued 
by the computer. Likewise, an antenna reverse pulse can be forced by real- 
time or stored commands issued from the computer if it is desired to 
reverse the antenna/receiver connections. 

Central Computer . The selected computer receives and accumulates 
the uplink command data and clock from the command demodulator/ 
configuration selector unit. Computer processing of the received data then 
consists of a number of basic command management functions including: 

1) Command decoding, polynomial code check for command verifica 
tion, command reformatting, and encoding for distribution. 

2) Command distribution as appropriate. Real time commands, 
requiring immediate execution, are manchester encoded and 
transmitted directly to the remote decoders. Stored com- 
mands, that are to be executed at a later time, are placed in 
the stored command memory. 

3) Storage of time dependent commands. Event dependent com- 
mands may also be accommodated if required. These stored 
commands consist of pulsed commands, 16 bit serial magnitude 
commands, and time -delay commands that determine when the 
pulse and magnitude commands are to be executed. 

4) Processing, control, and timing of the various types of stored 
commands to ensure their initiation and distribution to the 
remote decoders at the proper time. 

Remote Decoder. The remote decoders receive command addresses 
and manchester encoded command data from the central computer. The 
appropriate decoder recognizes and decodes the address, decodes the com- 
mand data into pulse or magnitude commands, and routes these commands 
to the proper user on the spacecraft. The distribution of the commands to 
the subsystem and experiment users is fully redundant; i. e. , the same com- 
mands can be issued by either of the two independent remote decoders. 
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Pyro Control Unit. This unit contains the necessary high current 
squib drivers for firing the pyrotechnic devices on the spacecraft. The 
squib drivers are enabled by receipt of two unique, contiguous pulse com- 
mands from a remote decoder. 

Telemetry Data Handling Functions 

In this centralized subsystem, three different types of units are 
involved with spacecraft telemetry and data handling operations. The 
functions of each of these types of equipment modules are briefly described 
below. 


Central Computer. This unit is the central element for the control 
and management ot telemetry and data handling functions. These basic con- 
trol and processing functions include: 

1) Telemetry format control — This includes generation of basic 
control signals for synchronization and assembly of telemetry 
data into desired data formats. Several types of control func- 
tions are performed, such as: 

a) Generation of addresses of the signal data to be sampled, 
in prescribed sequences, for insertion into the real-time 
downlink telemetry data stream or for storing into data 
storage memory for later transmission. Multiple telemetry 
data formats are generated to accommodate the various 
data transmission and data storage requirements at pre- 
scribed times during the mission scenario. This signal 
address data is manchester encoded and serially trans- 
mitted to the PCM encoder unit. 

b) Generation of frame synchronization and identification codes. 

2) Telemetry timing control — This includes generation of basic 
timing signals to control the major telemetry functions: i. e. , 
gathering, storing, and transmission of telemetry data. These 
timing signals assure the synchronization of data flow and 
select the proper rates for data manipulation, such as: 

a) Data sampling rates of both the remote multiplexers and 
of the stored data to be retrieved from memory. 

b) Transmission bit rates to accommodate communication link 
constraints during various phases of the mission. 

3) Telemetry data routing — Pulse code modulated NRZ-L data are 
received serially from the PCM^ encoder unit. Further manage- 
ment and distribution of the data then commences as required. 
This primarily consists of routing the data to the appropriate 
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destination, depending upon whether the data is intended for 
storage or for real-time telemetry, i- e. , to/from data storage 
or to processing functions that condition the data before trans- 
ferring it to the rf subsystem for transmission. 

4) Telemetry data processing — This includes control and execution 
of the various digital processing algorithms that are necessary 
to prepare the data for transmission, e.g. , functions such as 
convolutional encoding, modulation index selection, and biphase 
modulation. 

5) Telemetry data storage " This includes memory storage/ 
retrieval capability, for both data and appropriate timing control 
information, when it is desired to save the data for transmission 
at a later time. 

PCM Encoder. This unit receives serial manchester encoded 
address data from the central computer. The address (es) indicate the 
desired data source(s) to be sampled. Part of the address word is first 
decoded, to determine which remote multiplexer to interrogate, and then 
the address is relayed to the proper multiplexer. After the multiplexer has 
sampled the proper channel, the requested data are received back from the 
remote unit on a serial line and in burst PAM form. These data are then 
encoded into a PCM NRZ-L> format. When the incoming data represent the 
sampling of an analog signal, it is converted into an appropriate 8 bit PCM 
digital word. This unit then serially transmits the PCM encoded data back 
to the central computer for further processing. 

Remote Multiplexer . These modules receive the channel select 
portion of the signal address from the PCM encoder unit in manchester 
encoded form. They then sample the requested data point and transfer the 
signal information back to the PCM encoder. Each of these remote units 
has 32 input channels for gathering telemetry data of various types; namely, 
high level analog data, parallel bilevel digital data, and serial digital data. 
During the telemetry data gathering process, these remote units commutate 
the various types of data samples onto a PAM output line for multiplexed 
transmission back to the PCM encoder unit. 

Computer Hardware Survey 

A relatively extensive survey of aerospace computer developments 
was conducted in order to find appropriate computer hardware that might be 
available for Pioneer Venus application. The search concentrated on find- 
ing small general purpose computers with very low mass and power charac- 
teristics, e. g. , less than 4. 5 kg (10 lb) and 10 W with 4K words of 
memory. Although the primary objective was to locate small machines 
that were already fully developed, many of the computers that were reviewed 
were either still in the development stage or were larger and more power 
consuming than desired. 
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TABLE 4-28. CHARACTERISTICS OF SOME REPRESENTATIVE 

CANDIDATE COMPUTERS 




Physical Characteristics 

Memory Features 

M^anufacturer 
and Type 

Mas s 
(Weight) 

V olume 

Power , 
W 


Word 



kg 

(lb) 

cm^ 

(in3 ) 

Component 

Technology 

Length, 

bits 

Capacity, 
wo rds 

Type 

CDC'469 

J. 8 

(4) 

1, 165 

(70) 

4 

P-MOS LSI 

16 

(32) . 

8K 

(8K to 32K) 

Plated wire 
(core, semi) 

Autonetic s 
D-216 

2. 7 

(6) 

4, 100 

(250) 

32 

P-MOS LSL 

16 

(24, 32) 

8K 

(2K to 64K) 

Plated wire 

CSFC AOP 

3, 7 

(8) 

3,280 

(200) 

5 to 10 

TTL LSI 
(CMMA) 

18 

(24. 33) 

4K ' 1 

(4K to 64K) 

i 

Plated wire 
(core, semi) 

Honeywell 

HDC-301 

1. 4 

(3) 

1, 300 

(80) 

23 

P-MOS LSI 

16 

4K , 

(2K to 32K) 

Semic onductor 
(core, plated 
wire ) 



Other Computer Features 


Double 

Prec is Lon 


Add/Multipiy / 
Divide 
Time , 
psec 




Manufacturer 
and Type 

Add/ 

Subt. 

Mult./ 

Div. 

Number of 
Instructions 

Number of 
Interrupts 

Comments 

CDC-469 

H 

S 

6-8/26/76 

42 

3 

Optional clock speeds of 
1, 2, 2.5 Mhz; character- 
istics are for 1 MHz clock; 
also has a ^'direct 
execute'' interrupt 

Autonetics 

D-216 

H 

H 

2. 5/13, 75/23. 75 

68 

1 

Characteristics do not 
include case 

GSFC AOP 

S 

S 

4/30/60 

1 

55 

16 

Memories are power 
switched and dissipation 
depends on access rate; 
includes volume reserved 
for I/O control and inter- 
face buffers 

Honeywell 

HDC-301 

H 

S 

5/21/65 

47 

1 

1 

Characteristics include 
4 PC cards only without 
external case: 1 MHz 
clock; also has a "power 
recovery'' interrupt 


NOTESl 

1) Character istic a do not include power supplies; they include processor ^ I/O, and memory only. 

2) Characteristics are based on the word length, memory capacity, and memory type shown (optional 
word lengths, range of memory capacity, and memory types are shown in parenthesis). 

3) Instruction execution times shown are for single precision. 

4) Data flow is parallel for all machines. 

5) Double precision notations are H for hardware implementation and S for software implementation. 
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A general conclusion of the survey is that there are only a few 
computers of the desired class that have been fully developed. Although a 
few of these machines can be considered as available, none of them have 
yet been qualified for use on a space program. Based upon this Lack of 
space proven or space qualified hardware, none of the machines have been 
recommended for Pioneer Venus application. 

Table 4-28 gives a summary of some of the basic characteristics 
for four of the candidate computers that were investigated. These four 
machines are considered to be some of the best candidates for Pioneer 
Venus application due to their development status and their size and power 
characteristics. However, it is not intended to infer that these are the only 
aerospace computers that were considered as potential candidates for this 
space application during the course of this investigation. Rather, the table 
is intended to show only some of the representative characteristics of the 
class of computers that are of interest to Pioneer Venus, 

Some of the computers that were investigated merit some discussion 
because of their advanced development status. There is one general purpose 
computer of relatively small size that has recently been employed on a space 
program. However, its mass and power characteristics are slightly higher 
than could be justified for a Pioneer Venus application. This machine is 
the on-board processor (OBP) developed by NASA Goddard Space Flight Center . 
With 4K of core memory, the machine weighs approximately 8 kg (18 lb) 
and dissipates approximately 28 W excluding the power supply. The on-board 
processor is currently being used to perform a number of telemetry, com- 
mand, and control functions as an experiment on the OAO-C spacecraft that 
was launched in August 1972. The functional characteristics and features 
of this machine are considered to be well suited for performing these types 
of functions on a spacecraft, if only the mass and power were lower. 

In recognition of the need for a computer with lower mass and power 
on future spacecraft programs, GSFC is presently well along with the 
development of an advanced LSI version of the OBP. It is called the advanced 
on-board processor (A OP) and its characteristics are summarized in Table 4-28. 
The advanced on-board processor hardware and software are currently in 
an advanced stage of development, and the potential for many future applica- 
tions to various types of spacecraft functions is foreseen. Development 
activity on the advanced on-board processor has concentrated on its use as a 
centralized command and telemetry data processor. As such, it is designed 
to interface with the remote command decoders and remote telemetry multi- 
plexers that were developed for the OSO program by Hughes, This combina- 
tion of equipment provides a very modular data handling and control system 
that can be configured to meet the specific requirements of a spacecraft. 
Several flight models of the AOP are planned to be built in the near future. 

The advanced on-board processor is planned to be used on the ERTS-B and 
International Ultraviolet Explorer (lUE) programs. It is being considered 
for use on a number of additional programs including Nimbus G, EOS, 

OSO-J, and SATS. The first planned application of the AOP was for the 
High Energy Cosmic Ray experiment on the HEAO-A spacecraft, but com- 
pletion of the HEAO program has been delayed. 
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The CDC-469 appears to be the only candidate computer that is in 
relatively large production at the^ present time. It is also one of the 
smallest in physical size and lowest in power, making it one of the most 
attractive candidates. In addition, a large amount of supporting software 
has already been developed and debugged. It has been designed and tested 
to meet stringent Military Specifications and has already been considered 
for use on a number of space programs. This machine is considered to be 
a major contender for space usage, but it has not yet been qualified for a 
space application. 

The Autonetics D216 is a 16-bit member of the D200 family of com- 
puters. This series of LSI computers was designed to provide capability 
for a wide spectrum of military and space applications. Besides a number 
of missile and aircraft avionics applications, it is being considered for use 
on a number of space missions including the Space Shuttle and unmanned 
satellites, A D216S computer is currently planned to be employed in a 
Spac e Test Program satellite experiment being built by the Space Division 
of Rockwell International for SAMSO. This is the first D216S to be pro- 
vided by the Autonetics Division for space flight. The satellite, which will 
carry this experiment plus three other experiments to gather scientific data, 
is planned to be launched in early 1974, 

The HDC-301 is a small LSI computer that is currently under develop- 
ment at Honeywell, The computer is designed to use semiconductor memory 
modules although, like a large number of the other computers that were 
investigated, it can optionally accommodate either plated wire or core 
memory modules. The machine has primarily been designed for use in 
missile and aircraft avionics systems, and is presently planned to be 
employed in several of these types of applications. Its small size makes it 
a potential candidate for space usage, although no plans for the space 
application of this machine are presently known. 

Other computers that were investigated as potential candidates 
include: 

• Several other versions of the CDC-469 computer that are 
currently in development by CDC. 

• Other Rockwell International (Autonetics Division) computers 
of the D200 series class, 

• The Viking Lander 1975 computer being developed by Martin 
Marietta and Honeywell for NASA Langley Research Center. 

• The Viking Orbiter 1975 computer being developed by the 
Jet Propulsion Laboratory. 

• The HDP series of computer developments by Hughes. 
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• The programmable spacecraft control processor development 
for the International Telecommunications Satellite Consortium 
(Intelsat) and COMSAT by the TRW Systems Group. 

• The SKC-3000 LSI computer development by the Kearfott Division 
of the Singer Company. 

• European spaceborne computer developments by Selinia and by 
CNES for the ESRO. 

• Plus a number of other aerospace computer developments by the 
NASA agencies, SAMSO, AC Electronics, Arma, Bendix, Bunker 
Ramo, Burroughs, IBM, Litton, Nortronics, Raytheon, RCA, 
Rohm, Sperry Rand, Teledyne, TI, UNIVAC, and others. 
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5. THOR/DELTA BASELINE DESCRIPTION 


This section briefly describes the baseline designs for the 
Thor/Delta configuration of the command and telemetry data handling sub- 
systems for the four space vehicles; namely, for the probe bus and orbiter 
spacecraft and for the large and small probes. These subsystem designs 
were established prior to the decision to use the Atlas/Centaur launch 
vehicle; they therefore do not represent the current baseline and are briefly 
docurnented here for information purposes only. The current Atlas /Centaur 
baseline is described in Section 6, where the subsystems are discussed in 
more detail. 

Thor /Delta designs described here employ custom large scale 
integration (LSI) circuit technology to a large degree in order to minimize 
the mass of the subsystems. A summary of mass, power, and volume 
characteristics is shown in Table 5-1; it includes the command and data 
handling subsystems for all four vehicles. 

Subsection 5. 1 describes the command and data handling subsystems 
for both the probe bus and orbiter spacecraft, and the commonality and dif- 
ferences are pointed out. The subsystems are essentially identical, and 
employ a large amount of existing QSO hardware. The major difference is 
the addition of a data storage unit on the orbiter spacecraft, with minor 
differences in the pyro control units and in the telemetry data formats. 

The command and data handling subsystems for the large and small 
probes are described in Subsection 5.2. These subsystems are also 
common to a high degree. The small probe subsystem is essentially a sub- 
set of the large probe, since it is functionally similar, but requires fewer 
squib drivers and less circuitry for data gathering and commands. Besides 
the large amount of functional and circuit commonality between the probes, 
there is also some additional functional and circuit commonality between 
the probes and the spacecraft, particularly in the area of user interfaces. 
The hardware for the probes has limited physical commonality due to the* 
stringent packaging constraints. 


5. 1 SPACECRAFT COMMAND AND DATA HANDLING SUBSYSTEMS 

The command and data handling subsystems are highly modular in 
nature and are essentially identical on the probe bus and orbiter spacecraft. 
The fe*w differences that exist are explained in the following discussions. 
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TABLE 5-1. CHARACTERISTICS SUMMARY - COMMAND 
AND DATA HANDLING SUBSYSTEMS 



Characteristics 

Thor /Delta 
Vehicle Subsystems 

Mass (Weight) 
kg (lb) 

Power, 

W 

Volume, 

3 3, 

cm (in ) 

Probe bus 





Command subsystem 

7. 1 


6.9 

9, 600 ( 586) 

Data handling subsystem 

5. 8 


8. 6 

7, 060 ( 431) 

Totals 

12.9 

(28, 3) 

15.5 

16, 660 (1017) 

Orbiter 





Command subsystem 

6. 6 

(14.5) 

6, 9 

9, 060 ( 553) 

Data handling subsystem 

9.9 

(21.8) 

8.9 

9. 350 { 571) 

Totals 

16.5 

(36.3) 

15. 8 

18,410 (1124) 

Large probe 



; Cruise/ 
1 descent 


Command and data 
handling subsystem 

2. 1 

( 4.7) 

0. 06/4. 2 

2, 620 ( 160) 

Small probe 





Command and data 
handling subsystem 

1.2 

( 2.7) 

0. 06/3. 1 

1, 340 ( 82) 


Command Subsystem 


Figure 5-1 shows a block diagram of the command subsystem. It 
consists of four basic types of units, each of which employs complete dual 
redundancy. They are the dual demodulator /selector, the dual central 
decoder, three dual remote decoders, and the dual pyro control unit. The 
following is a brief description of the major functions performed by each 
of these units. 
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1) Dual demodulator / selector 

• Receives and demodulates subcarrier into command data 
and clock signals 

• Provides receiver reverse switching to select the connec- 
tion combination between the receivers and antennas 

2) Dual central decoder 

• Decodes and processes the incoming command data 

• Performs a polynomial code check for command 
verification 

• Provides storage for time dependent command sequences 

• Initiates execution of the commands at the proper time 

• Distributes commands to the proper remote decoder 

3) Dual remote decoder 

• Recognizes and decodes the appropriate command 
addresses 

• Receives and decodes command data into pulse or mag- 
nitude commands 

9 Distributes pulse commands and magnitude data to space- 
craft users (and to probes on probe bus) 

4) Dual pyro control unit 

• Receives interlocked pulse commands from remote 
decoder s 

• Provides high current switching to fire pyrotechnic 
devices 

Table 5-2 summarises the basic functional characteristics of the 
command subsystem for both the probe bus and orbiter spacecrafts As 
indicated in the table, the characteristics are identical with one exception; 
the probe bus has 50 percent more pyrotechnic drivers and initiators than 
the orbiter, since the probe bus requires more squib firing events • 
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TABLE 5-2, PROBE BUS/ORBITER SPACECRAFT COMMAND 
SUBSYSTEM FUNCTIONAL CHARACTERISTICS SUMMARY 


Parameter 


Characteristics 


Probe Bus 


Orbiter 


Command mode 

Command type 

Command initiation 

Command uplink 

Command word size 
Bit rate 
Modulation 

Probability of false command 
Number of pulse command outputs 
Number of magnitude command outputs 
Word size of magnitude commands 
Command storage capacity 
Resolution of command executions 

Number of pyrotechnic drivers 

Maximum delay between concurrent 
fire pulses 

Number of pyrotechnic initiators fired 
(capability) 


Real-time or stored 
Pulse or magnitude 
Ground command^ timer, or event 

36 bits (includes 7 bit error code) 

1 bps 
PSK 
1 X 10"^ 

192 

12 

10 bits 

2048 bits (85 words maximum) 

±125 ms (stored mode) 

6 redundant pairsj4 redundant pairs] 
0. 1 ms 


30 


18 


Hardware Design Description 

A summary of the hardware derivation and characteristics is shown 
in Table 5-3. In addition to presenting the mass, power, and volume charac- 
teristics for both the probe bus and orbiter spacecraft, the table briefly des- 
cribes the source and type of hardware employed. 
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TABLE 5-3. MODULAR COMMAND SUBSYSTEM - HARDWARE 
DERIVATION AND CHARACTERISTICS 



* Hardware Derivation 

Hardware Characteristics 

Unit 

Thor /Delta 
Probe Bus 

Thor/ Delta 
Orbiter 

Mass 

(Weight), 

(lb) 



Dual demodulator/ 
antenna selector 

Motorola - POV 

(Uses 98 percent 
Viking orbiter 
circuits; MSI; 
printed circuit 
boards) 

Same 

2, 1 

(4.6) 

3.0 

3. 080 (188) 

Dual central decoder 

New design 

Same 

1.8 

(3.9) 

3.6 

3, 130 (191) 


(Uses 50 percent 
OSO circuits and,^,^,, 
new LSI; MIC AM'"'" 
and printed cir- 
cuit boards) 

\ 





Dual remote decoder 

OSO 

Same 

1.8 

(4.0) 

0.3 

1, 720 (105) 


(three dual units; 
existing LSI; 
printed circuit 
boards ) 






Dual pyro control unit 

New design 

Same Design | 

1.4 

(3.0) 

-0- 



(three slice unit; 
modules) 

(two slice 
unit) * 

0.9 

(2.0) 

-0- 1 



Probe bus totals 

7, 1 

(15.5) 

6.9 

9, 630 (586) 


Orbiter totals 

6, 6 

(14.5) 

6.9 1 

1 

9, 060 (553) 


“^'Where two sets of values are given, the bottom line is for the orbiter spacecraft. 
=!-'*MICAM is the acronym for Hughes "microelectronic assembly method" 
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As indicated in the table, three o£ the units are planned to be built by- 
Hughes and utilize OSO designs. Of these units, the dual central decoder and 
dual remote decoder employ custom LSI circuit technology as a means for 
reducing mass; the pyro control unit does not employ LSI, since this techno- 
logy is not as amenable to the high current pyrotechnic circuit applications. 

The dual demodulator /antenna selector unit is planned to be pur- 
chased from Motorola. This unit is a modification of the command demodu- 
lator that was developed for the Viking Orbiter program; it utilizes MSI 
circuit technology. 

Data Handling Subsystem 


A block diagram of the data handling subsystem is shown in Fig- 
ure 5-2. It also consists of four basic types of units; remote multiplexers 
(seven required), dual PCM encoder, dual telemetry processor, and orbiter 
data storage unit that is required only on the orbiter spacecraft. As implied 
by the unit names, the PCM encoder and telemetry processor employ com- 
plete dual redundancy. Redundancy is achieved in the remote multiplexers 
through redundant channel assignments of critical data inputs. While the 
baseline employs a nonredundant orbiter data storage unit, the splitting 
of the storage into two memories is strongly being considered; this would 
provide graceful degradation such that, if one fails, 50 percent of the total 
capacity is still usable. 

The following is a brief description of the major functions performed 
by each of these units: 

1) Remote Multiplexer 

• Accepts data from spacecraft subsystems and science 
instruments (and from probes on the probe bus) 

• Multiplexes analog, serial digital, and bilevel discrete 
input data onto a single output line to be transferred to 
the PCM encoder 

• Receives address control data from the PCM encoder 
to provide channel selection 

• Provides signals to data handling subsystem users to 
control the sampling of digital data 

2) Dual PCM Encoder 

• Accepts PAM analog data and serial digital telemetry data 
from remote multiplexers 

• Digitizes analog data into 8 bit words and combines it with 
digital data into a PCM bit stream to be transferred to the 
telemetry processor 
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FIGURE 5-2. MODULAR DATA HANDLING SUBSYSTEM 
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• Relays address control data from the telemetry processor 
to the remote multiplexers for channel selection 

3) Dual Telemetry Processor 

• Provides a versatile telemetry frame format that is based 
upon preprogrammed sampling sequences and is structured 
in flight by ground conomand 

• Generates addresses of data inputs to be sampled 

• Encodes, modulates, and controls amplitude of PCM data 
and transfers it to the spacecraft transmitters or memory 

4) Orbiter Data Storage Unit 

• Provides storage for scientific and engineering data 

Table 5-4 presents a summary of the basic functional characteristics 
for the data handling subsystem. It shows the similarity and differences 
between the probe bus and orbiter spacecraft. As indicated in the table, 
the characteristics are identical with two exceptions. First, data storage 
is only required on the orbiter, and second, the subframe data formats are 
unique on each of the spacecraft. The hardware is essentially the same for 
the data formats, however, since they both employ the same number of 
read-only memory (ROM) devices; the difference is that the ROMs are 
preprogrammed to provide different formats that are consistent with the 
different mission requirements. 

Hardware Des ign Description 

The derivation and characteristics of the data handling subsystem 
hardware are shown in Table 5-5. The table briefly describes the source 
and type of hardware employed in addition to presenting the mass, power, 
and volume characteristics for both the probe bus and orbiter spacecraft. 

Three of the data handling units are planned to be built by Hughes. 

Of these units, the remote multiplexer and dual PCM encoder units are 
existing OSO units, whereas the dual telemetry processor is a new design 
that employs OSO circuits to a large degree. The remote multiplexer and 
dual telemetry processor employ a large amount of custom LSI circuitry 
as a means to reduce mass. 

The data storage unit is planned to be purchased from Electronic 
Memories. A previously designed core memory unit, of the company's 
SEMS series, will be modified to meet the storage and interface 
requirements. 
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TABLE 5-4. PROBE BUS/ORBITER SPACECRAFT 
DATA HANDLING SUBSYSTEM FUNCTIONAL 
CHARACTERISTICS SUMMARY 


Parameter 


Characteristics 


Probe Bus 


Orbiter 


Word size 

Number of data inputs 

Analog -to -digital conversion accuracy 
Data storage capacity 
Data bit rates 


8 bits 
224 

±0. 4% (8 bits) 

None I .393 kilobits 

8 to 2048 bps 


Downlink data format 

Subframe length 

Telemetry Frame length 

Number of preprogrammed (ROM) 
32 word subframes 

Number of downlink formats 


Error code 
Modulation type 
Subcarrier frequency, Hz 


32 words 

512 words, 16 subframes 

16 bus unique j 16 orbiter unique 

All combinations of from 1 to 
16 subframes in groups of 16 
are possible; actual combina- 
tions will be selected by 
ground command 

Convolutional, length 32, rate 1/2 
PCM/PSK 


(TBD) 


(TBD) 
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TABLE 5-5. MODULAR DATA HANDLING SUBSYSTEM - 
HARDWARE DERIVATION AND CHARACTERISTICS 



' Hardware Derivation 

* 

Hardware Characteristics 

Unit 

Thor/ Delta 
Probe Bus 

Thor/ Delta 
Orbiter 

Mass (Weight), 
hg (lb) 

Power, 

W 

Volume, 
cm^ -(in^) 

Remote multiplexer 

OSO 

(seven single 
units; existing 
LSI; printed 
circuit boards) 

Same 

1.4 ( 3.0) 

0, 3 

970 ( 59) 

I>ual PCM encoder 

■ 

OSO 

(Dual unit; exist- 
ing MSI; 

MIC AM, 
printed circuit 
boards, 3.nd 
modules) 

Same 

2.8 (6.3) 

2. 6 

3, 500 (214) 

Dual telemetry 
processor 

New design 

(Uses 70 percent 
OSO circuits & 
new LSI; MICAM 
and printed cir- 
cuit boards) 

Same 

(modified 

ROM 

formats) 

1.6 ( 3.5) 

5*7 

2,590 (158) 

Data storage unit 

Not required 

Core - POV 

(modified 

electronic 

memories 

design) 

4.1 ( 9.0) 


2, 290 (140) 


Probe bus totals 

5.8 (12.8) 

8 . 6 

7, e60 (431) 


Orbiter totals 

9.9 (21.8) 

8.9 

9, 350 (571) 


*Where two sets of values are given, the bottom line is for the orbiter spacecraft 
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5. 2 PROBE COMMAND AND DATA HANDLING SUBSYSTEMS 
Functional Description 

, The coTnmand functions and the data handling functions are combined 

subsystem in both the large and small probes. The subsystem 
IS divided into two control items or units; the command/data unit and the 
pyro Control unit. Figure 5-3 shows a block diagram of the subsystem. 

The command/data unit; 

• Provides an accurate timer for initiation of the pre-entry 
sequence 

• Initiates pulse commands from real-time events and stored 
command sequences 

• Multiplexes and encodes analog and digital input data to form a 
serial PCM/PSK bit stream 

• Provides multiple stored formats and data rates for downlink 
data transmission 

• Provides for data storage during entry blackout 


The pyro control unit provides high current switching capability for 
firing of pyrotechnic devices. 

Table 5-6, summarizes the functional characteristics of the command 
and data handling subsystems of the large and small probes. 

Hardware Design Description 


A summary of the hardware derivation and the mass, power and 
volume characteristics of the large and small probe subsystems is pre- 
sented in Table 5-7. New design was planned for both probes since 
appropriate existing hardware was not available which would meet the 
performance requirements plus the environmental and packaging constraints. 

From an electrical design standpoint, minimization of mass and 
volume was accomplished by designing for minimum parts count, primarily 
by use of LSI. From a mechanical design standpoint, packaging techniques 
were investigated to ensure the ability to withstand high deceleration forces 
during entry into the Venus atmosphere; also, conformal packaging was 
considered to make optimum use of the spherical envelope of the probe pres- 
sure vessel. ^ 


There is much commonality between the large and small probe 
designs due to their functional similarity; many circuits are identical for 
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TABLE 5-6. LARGE /SMALL PROBE COMMAND AND 
DATA HANDLING SUBSYSTEMS FUNCTIONAL 
CHARACTERISTICS SUMMARY 


Parameter 


Comma nd 

Cruise timer 
Range 

Stability to 40 °C) 

Resolution 

Descent timer 

Range 

Stability (-20® to +65® C) 

Resolution 

Command mode 

Command type 

Command initiation 
Number of event inputs 
Number of commands 

Total command executions 

Number of pyrotechnic drivers 

Maximum delay between concurrent fire pulses 
Number of pyro initiators fired (capability) 


Data handling 
Word size 

Number of analog inputs 
10 bit accuracy 

8 bit accuracy/10 bit resolution 
Number of digital inputs 
10 bit serial 
Bilevel discrete 
Data storage capacity 
Number of data formats 
Data bit rates 
Error coding 
Modulation type 
Subcarrier frequency 


Cha racteristic 


Large Probe 


Small Probe 


20 days 


1 X 10“^ (17, 3 sec in 20 days) 
1 . 6 sec 


13. 6 minutes (between recycle) 
5 X 10"^ 

0. 1 sec 


Stored 

Pulse 


Time or Event 
8 


128 

4 redundant pairs, multiple 
2 nonredundant, multiple 
10 nonredundant, single 

0. 1 me 

40 


32 


64 


1 redundant pair, multiple 
1 nonredundant, multiple 


32 

44 

8 

’ 28 

409 6 bite 
3 

276 or 184 bps 


8 

20 

4 

20 . 
512 bits 
2 

16 bps 


Convolutional, length 32, rate 1/2 
PCM/PSK 

441 6 Hz I 256 Hz 
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TABLE 5-7. LARGE AND SMALL PROBES COMMAND AND DATA HANDLING 
SUBSYSTEM HARDWARE DERIVATION AND CHARACTERISTICS 




Hardware Characteristics 

Unit 

Thor /Delta 
Hardware Derivation 

Mass 

kg 

(Weight), 

(lb) 

Power 

Cruise /Descent, 
W 

Volume, 
cm^ (in^) 

Large probe command /data 
unit 

New design 

1. 13 

(Z.5) 

0. 06/4. 2 

1, 426 ( 87) 

(Printed circuit boards 
and modules; LSI) 





Large probe pyro control 
unit 

New design 

1. 00 

(2,2) 

(Transient only) 

1, 196 ( 73) 

(Uses 50 percent of 
probe bus circuits; 
modules) 





Total 

Z. 13 

(4.7) 

0. 06/4. 2 

2, 622 (160) 

Small probe command /data 
unit 

New design 

I. 00 

(2.2) 

0. 06/4. 2 

1, 180 ( 72) 

(Uses 50 percent of 
large probe circuits; 
printed circuit boards 
and modules; LSI) 





Unit probe pyro control 

New design 

0. 2Z 

(0.5) 

(Transient only) 

164 ( 10) 


(Uses 80 percent 
large probe circuits; 
modules) 





Total 

1. ZZ 

(2.7) 

0. 06/4. 2 

1, 344 ( 82) 













both. The experiment interface specification is identical for both probes and, 
in fact, is nearly identical to that of the probe bus/orbiter spacecraft; a sum- 
mary of the interface specification can be found in Section 4 of this volume. 
Functional blocks in Figure 5-3 that are identical for both the large and 
p 37 obes include the cruise regulator /timer, data encoder, and the 
regulator and dc-dc converter. In addition, circuit elements such as multi- 
plexer switches, memory storage devices, command decoders and drivers, 
timing circuits and squib drivers are identical but are used in smaller num- 
bers in the small probe. This results from the difference in magnitude of 
requirements between the two probes; e. g. , number of data inputs, storage 
capacity, number and type of data formats, number of stored command 
sequences and the number of pulse command outputs. The pyro control 
unit in the small probe is considerably smaller than that of the large probe, 
although the individual switching circuits are the same for both. 

Large Scale Integration 


Custom developed LSI circuits are used to minimize mass and 
volume in the probe design. They are used only in the command/data 
unit, since they do not apply as well to the circuits in the pyro control 
unit. A total of three chips would be developed for use in both probes - 
Each LSI chip is used once in each probe. Two of the three types use 
PMOS technology; the third, which is used for the cruise timer, uses 
CMOS technology for ultra -low power dissipation- This use of LSI has 
reduced the overall command and data handling subsystem mass and 
volume by approximately 40 percent, as compared to the use of IC and MSI 
technology. 
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6. ATLAS/CENTAUR BASELINE DESCRIPTION 


This section describes the Atlas/Centaur baseline designs for the 
command and data handling subsystems on the probe bus, the orbiter, the 
large probe, and the small probe vehicles. Table 6-1 presents a summary 
of mass, power, and volume characteristics for the subsystems on ail four 
spacecraft. 

This baseline differs in a number of respects from the Thor/Delta 
baseline described in Section 5. A major difference is that custom LSI 
circuit technology is employed to a much lesser degree in the Atlas/Centaur 
version of these subsystems since they are not as mass and volume con- 
strained as those for the Thor /Delta configuration; this results in lower cost 
equipment. Also, several functional differences are due to program level 
changes made subsequent to the decision to use the Atlas/Centaur launch 
vehicle. The program changes affecting these subsystems were primarily: 

1) The decision to utilize the same launch opportunity for both the 
multiprobe and orbiter missions, resulting in two spacecraft in 
transit at the same time 

2) The decision to use a type II trajectory for the orbiter in order 
to allow separation of the launch windows 

3) Revised science payload requirements 

The subsystem baselines described in this section reflect these changes and 
the corresponding new requirements. 

Subsystem requirements affected by the above program decisions are 
described in subsection 6. 1, 

Subsection 6.2 discusses the design rationale and tradeoffs for the 
Atlas/Centaur baseline and reflects the impact of these new requirements. 
Since the tradeoff studies discussed in Section 4 of this volume were pri- 
marily Thor /Delta oriented, each is reviewed to show its correlation and 
the applicability of its results to the Atlas/Centaur design; changes in the 
results and conclusions of those studies caused by the new requirements are 
noted. 
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TABLE 6-1. ATLAS/CENTAUR COMMAND AND DATA HANDLING 
SUBSYSTEM CHARACTERISTICS SUMMARY 




Characteristic s 



Mass 

Power, 

W 

Volume 

Subsystems 

kg 

(lb) 

3 

cm 

(in^) 

Probe bus 






Command subsystem 

9. 8 

(21. 7) 

6. 9 

15, 060 

( 919) 

Data handling subsystem 

7. 8 

( 17.2) 

8. 7 

11, 180 

( 682) 

Totals 

17. 6 

(38.9) 

15. 6 

26, 240 

(1, 601) 

Orbiter 






Command subsystem 

9.8 

(2L 7) 

6. 9 

15, 060 

( 919) 

Data handling subsystem 

16.9 

(37.2) 

11. 7 

20, 810 

(1, 270) 

Totals 

26. 7 

( 58. 9) 

18. 6 

35, 870 

(2, 189) 

Large probe command and 
data handling subsystem 

3. 5 

{ 7.8) 

Cruise / 
descent 
0. 04/8. 3 

4, 140 

( 253) 

Small probe command and 

2. 7 

( 5.9) 

0. 04/5. 8 

2, 930 

( 179) 

data handling subsystem 







The baseline designs for the probe bus and orbiter spacecraft com- 
mand and data handling subsystems are described in subsection 6. 3. These 
designs are practically identical and make extensive use of previously 
developed OSO hardware. As with the Thor/Delta design, the major differ- 
ence is the addition of a data storage unit on the orbiter spacecraft; also, 
minor differences exist in the telemetry data formats. 

Subsection 6.4 describes the command and data handling subsystem 
baselines for the large and small probes; these designs are common to a 
high degree. Essentially, the small probe subsystem is a subset of the 
large probe; although the designs are very similar, the small probe requires 
fewer multiplexer elements for gathering data, fewer command decoding and 
command outputs, fewer memory elements for data storage, and fewer 
drivers for firing of pyrotechnic initiators. 


6-2 




6. 1 SUBSYSTEM REQUIREMENTS IMPACT 


Requirements for command and data handling subsystem performance 
have been modified due to the recent changes in the baseline mission which 
were discussed in the preceding paragraphs. The changes are summarized 
as follows: 

1) Uplink bit rate — bus changed from selectable 1, Z, 4, or 8 bps 
to a single 4 bps. This is possible due to changes in the link 
performance which eliminate the need for bit rates less than 

4 bps. The 8 bps rate was not required and was eliminated to 
minimize changes to existing hardware. 

2) Command rnemory size — has changed from 64 to 85 24-bit 
words. This change was required due to increased commanding 
necessary at periapsis for the radio occultation experiment 
antenna positioning. 

3) Receiver reverse unit — The RRU algorithm has been changed to 
accommodate switching from the high gain antenna to the omni 
antennas in the event of an uplink failure. 

4) Pyrotechnic damages have been necessary to accommodate 
changes in the science experiments and mechanisms. 

5) Orbiter data storage size — has increased from 393 kilobits to 
1 megabit due to increased science instrument data rates at 
periapsis. 

6) Simultaneous real time and stored data processing requirem ents — 
has been necessary due to the volume of data collected at orbiter 
periapsis. Downlink capability is limited to 128 bps through the 
last half of the orbiter mission, which requires storing of the 
remaining science periapses requirement at approximately 

512 bps- 

7) Additional data formats and bit rates — were required to fit the 

I orbiter periapsis science data storage requirements to realizable 
data storage devices. Bit rates have been added to the small 
probe to accommodate additional science data. 

8) Command and data channel allocations — have changed for all sub- 
systems due to design modifications and the minimum changes. 

9) Probe cruise timer — timing requirement has changed from 20 to 
23 days. This change was implemented subsequent to the mid- 
term design review due to the desire to spread out the probe 
release sequence of events and provide longer periods of 
uninterrupted tracking to reduce entry dispersions. 
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10) Pressure/acceleration switches ~ a bookkeeping change was 
made to include these switches in the probe command and data 
subsystem from the mechanisms subsystem. 

11) Subcarrier frequencies ’"have changed for the large and small 
probe to accommodate the transponder interface requirements* 

12) Data storage ~ for the large probe has decreased slightly due to 
elimination of the shock layer radiometer. 

An overall summary of command assignments, data channel assign- 
ments, and command and data system requirements has been tabulated. 
Multiprobe bus command requirements are given in Table 6-2; assignments 
are shown in Table 6-3. Orbiter spacecraft command requirements are 
given in Table 6-4; assignments are shown in Table 6-5. Large and small 
probe command requirements are presented in Table 6-6. 

TABLE 6-2. MULTIPROBE BUS COMMAND REQUIREMENTS 
Demodulate, decode, distribute ground commands 
Store commands for later execution, 17 words minimum storage 
PCM/PSK/PM or PCM/FSK/PM modulation 
4 bps command rate 
3 6 -bit command word 
Pulse commands 

144 engineering 
14 instrument 
Magnitude commands 
8 engineering 
Interlocked commands 
5 engineering 
2 science instrument 
Threshold: 1 x 10‘^ BER 

-9 

Probability of executing a false command at threshold: 1x10 
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table 6^3. MULTIPROBE BUS COMMAND ASSIGNMENT SUMMARY 


Subsystem 

Pulse 

Magnitude 

Interlocked 

Command 

6 

1 

0 

Communications 

21 

0 

0 

Control /propuls ion 

17 

1 

1 

Data handling 

6 

2 

0 

Power 

78 

0 

0 

Probes 

16 

4 

4 

Science 

14 

0 

2 

Thermal 

0 

0 

0 

Total 

158 

8 

7 


TABLE 6 - 4 . ORBITER SPACECRAFT COMMAND REQUIREMENTS 
Demodulate, decode, distribute ground commands 
Store commands for later execution, 85 words minimum storage 
PCM/PSK/PM or PCM/FSK/PM modulation 
4 bps command rate 
3 6 -bit command word 

Pulse commands 

124 engineering 
43 instrument 

Magnitude commands 

5 engineering 
2 instrument 

Interlocked commands 

2 engineering 
2 instrument 

Threshold: 1x10^ ‘ 

Probability of executing a false command at threshold: lx 10 
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TABLE 6-5. ORBITER COMMAND ASSIGNMENT SUMMARY 


Subsystem 

Pulse 

Magnitude 

Interlocked 

Command 

6 

1 

0 

Communications 

19 

0 

0 

Control/propulsion 

27 

2 

2 

Data handling 

9 

2 

0 

Power 

63 

0 

0 

Science 

43 

2 

2 

Thermal 

0 

0 

0 

Total 

167 

7 

4 


TABLE 6-6. SUMMARY OF PROBE COMMAND REQUIREMENTS 


Subsystem 

' ■— ■ ' 

Large Probe 

Small Probes 

Data handling 

11 

11 

Mechanisms 

16 

3 

P owe r 

8 

8 

Science 

6 

4 

Total i 

41 

i 

26 


Probe bus handling requirements are shown in Table 6-7; telemetry 
channel requirements are presented in Table 6-8* Orbiter spacecraft 
handling requirements are given in Table 6“9; telemetry channel require- 
ments are shown in Table 6-10. A summary of probe telemetry channel 
requirements is given in Table 6-11. 
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TABLE 6-7. PROBE BUS DATA HANDLING REQUIREMENTS 


Multiplex, format, encode, and modulate spacecraft and 
experiment data 

PCM/PSK/PM modulation 

Convolutional encoding: K"32;R = 1/2 

8 to 2048 bps data rates 

Minor frames: 16 

Major frames: 16 

Engineering data channels 

107 analog 
39 serial digital 
0 discrete 

Science instrument data channels 

7 analog 
6 serial digital 
0 discrete 


TABLE 6-8. PROBE BUS TELEMETRY CHANNEL 
REQUIREMENT SUMMARY 


Subsystem 

Analog 

Digital 



Total 

Command 

0 

6 

6 

Communications 

12 

2 

14 

Control /propuls ion 

11 

11 

22 

Data handling 

4 

9 

13 

Power 

40 

6 

46 

Probes 

22 

5 

27 

Science 

7 

6 

13 

Thermal 

18 

0 

18 

Subtotal 

114 

45 

159 

Spare 



33 

Total ’ 



192 
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TABLE 6 - 9 . ORBITER SPACECRAFT DATA 
HANDLING REQUIREMENTS 

Multiplex, format, encode, and modulate spacecraft and 
experiment data 

Store data for later transmission to earth 
PCM/PSK/PM modulation 
Convolutional encoding: K - 32; R = 1/2 

8 to 2 048 bps data rates 
Minor frames: 16 

Major frames: 16 

Engineering data channels 
100 analog 
34 serial digital 
0 discrete 

Science instrument data channels 
26 analog 
1 7 serial digital 
0 discrete 

Storage capacity: 1 megabit 
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Table 6-io. orbiter spacecraft telemetry channel 

REQUIREMENT SUMMARY 


Subsystem 

Analog 

Digital 

Total 

Command 

0 

6 

6 

Communications 

12 

2 

14 

Control /propuls ion 

24 

11 

35 

Data handling 

4 

9 

13 

Power 

42 

6 

48 

Science 

26 

17 

43 

Thermal 

18 

0 

18 

Subtotal 

126 

51 

177 

Spare 



15 

Total 


— 

192 


6. 2 DESIGN RATIONALE AND TRADEOFFS 

This subsection describes the rationale used in the design of the 
command and data handling subsystems for the Atlas /Centaur launch vehicle 
in each of the probe bus/orbiter spacecraft and the large and small probes. 
In particular, any tradeoff studies which were performed subsequent to, or 
resulting from, recent changes to the Pioneer Venus program requirements 
will be discussed. In some instances, the new requirements may have 
affected the criteria used in performing the studies reported in subsec- 
tions 4. 1 and 4. 2, thereby affecting the results or conclusions of those 
studies. Each of the studies reported previously will be discussed, with 
any changes in the results noted. 

The principal effect on the command and data handling subsystem 
resulting from the decision to use the Atlas /C entaur launch vehicle is that 
the development of custom large scale integrated circuits is no longer justi- 
fied from a cost standpoint since mass and volume are no longer as severely 
limited as for the Thor /Delta vehicle. Thus, mass and volume are higher 
than for the Thor/Delta design in both the spacecraft and the probes. 
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TABLE 6-11. SUMMARY OF PROBE TELEMETRY 
CHANNEL REQUIREMENTS 


Sub system 

Analog 

Serial Digital 

Binary Discrete 

Liarge probe 




Data handling 

4 

3 

2 

Instrumentation 

7 

0 

0 

Power 

5 

2 

0 

Science 

16 . 

6 

0 

Thermal 

5 

0 

0 


— 

— 

— 

Total 

37 

1 1 

2 

Small probe 




Data handling 

4 

3 

1 2 

Power 

4 

1 

0 

Science 

1 7 

5 

0 

Thermal 

4 

0 

0 


— 

— 

— 

Total 

19 

9 

2 


The revised science requirements and new mission set caused many 
subsystem requirements to change, necessitating a redefinition of data 
formats, data storage requirements, downlink bit rates, and so forth. Of 
particular significance was a considerable increase in the data storage 
requirements for the orbiter spacecraft. 

Command Subsystem Design Changes and Ra tionale 

Changes to the command subsystems in the probe bus/orbiter space- 
craft and the large and small probes are summarized below. 

For all four vehicles, the planned use of custom LSI was abandoned to 
achieve a lower cost design in light of the less severe mass and volume con- 
straints upon the Atlas /Centaur design. 
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For the probe bus/orbiter spacecraft: 

1) Subsystem units which were previously dual units were separated 
into two identical redundant units in order to make them identical 
to existing OSO hardware; this results in a lower cost design. 

The slight increase in mass and volume is felt to be acceptable 

in view of the less stringent mass constraints upon the Atlas/ 
Centaur design. 

2) The real time uplink bit rate was changed from a selectable 1, 2, 4, 
or 8 bits bps to a single 4 bps in order to minimize modifications 

to existing command demodulator hardware: both demodulator 
candidates presently under consideration operate at the higher 
rate. The change was permitted as a result of improvements to 
the uplink performance, 

3) The circuitry used to control the antenna/receiver select switch 
was relocated from the demodulators to the central decoder since 
its location in the demodulator required a change to existing 
hardware. In addition, a new algorithm for selecting the 
receiver /antenna connection would have required additional 
interfacing between the central decoder and the demodulator; 
relocating the control circuitry now results in a minimum 
interface. 

4) The command memory was changed from a single input (entry 
point) shift register to a multiple entry point shift register in 
order to facilitate reloading of incorrectly received commands. 

The change in command storage requirements from 64 to 

85 words did not impact the command memory hardware per se, 
since the 85 word capability previously existed; however, the 
probability of correctly loading 85 words is not as high as with 
64 words, thus making more desirable the change to the multi- 
ple entry point memory. This change, in turn, necessitated 
adding a l6-bit shift register to the existing 2048-bit command 
memory in order to have an integral number of commands (86) 
in memory. 

5) The requirement for pyrotechnic drivers was revised from 6 to 5 
on the multiprobe bus and from 3 to 5 on the orbiter as a result 
of new science and engineering requirements for the two mis- 
sions. This enables a common pyro control unit design for both 
spacecraft, resulting in a considerable reduction in costs 
associated with product design and documentation for a separate 
control item. 

6) The number of spare pulse commands has increased and the 
number of spare magnitude commands has decreased as a result 
of revised command requirements. 
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For the probes (command portion of the command and data handling 
subsystem): 

1) A bus voltage regulator was added to the command and data 
handling subsystem as a result of the decision to change to an 
unregulated bus on the probe s* 

2) The range of the probes* cruise timer was increased to 24 days 
to allow for a longer period from probe separation to entry. 

3) The use of a switching regulator for the cruise timer was 
reevaluated due to the change to a higher battery voltage in the 
probes. 

4) The number of spare pulse command outputs was decreased due 
to an increase in command requirements. 

5) The number of pyrotechnic drivers was increased to accommo^ 
date new science payload requirements. 

6) The pyro control unit (PCU) ON /OFF switch was relocated from 
the power subsystem to the PCU; this relay switch now performs 
the dual function of arming the PCU switches and blocking leakage 
current during the probe cruise period. 

7) Pressure and acceleration switches were reassigned to the 
command and data handling subsystem and are now reflected 
in subsystem hardware characteristics. 

Command Subsystem Trade Studies 

Each of the trade studies reported in subsection 4. 1, as it may be 
affected by the changes outlined above, is discussed below. 

Command Interface Methods 

The interface definition summarized in subsection 4. 1 was not 
affected by the changes in program requirements. 

Prevention of S pacecraft Inadvertent-Irreversible Command Execution 

The results of the original study were not affected by the changes in 
program requirements. 

Spacecraft Command Storage Analysis 

Recent changes caused the command storage requirement to change 
from 64 to 85 command words. An additional requirement was placed on the 
command memory such that the probability of loading the memory correctly 
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would be greater than 0. 996 in a 30 min period exclusive of verification and 
round trip delay time* Because of the time limitation on loading and correct- 
ing the command memory, it was decided that a random access memory 
(RAM) or a shift register with multiple entry points would be required. 
Investigation of both techniques showed that the long shift register with mul- 
tiple entry points would require less hardware and power than a RAM. The 
study concluded that the long MOS shift register memory is still applicable. 
Additional circuitry, however, would be needed to provide more than one 
entry point. 

Probe Cruise Timer 

The decision to use the Atlas /Centaur launch vehicle reinforces the 
selection of the switching regulator/ 1 MHz oscillator made in the original 
study since the mass constraint is not as severe as it was previously. The 
selected approach consumes 30 mW, whereas the low frequency alternate 
consumes 15 mW. The mass penalty paid for the higher power circuit is 
approximately 0. 12 kg (0*27 lb) per probe battery or an overall mass differ- 
ence of 0. 48 kg (1* 1 lb) for the total battery complement. This is felt to be 
an acceptable tradeoff in light of the advantages of better stability and lower 
technical risk- 

A 30 mW savings was realized by using a switching instead of a 
series regulator with the 1 MHz oscillator, resulting in an overall mass 
reduction for the total probe battery complement of almost 0. 9 kg (2 lb). 

If the probe battery voltage were increased to 28 V, as might be the case 
if an unregulated bus concept were adopted, the series regulator approach 
would consume approximately 160 mW. Then the battery mass savings 
realized by using the switching regulator approach at 40 mW dissipation (up 
from 30 mW due to lower efficiency at 28 V) would be an even more signifi- 
cant 3. 9 kg (8* 5 lb). Thus, it is felt that the use of a switching regulator 
and the 1 MHz crystal oscillator, as proposed in the original study, still 
represents the optimum design approach* 

Receiver Reverse Unit 


The discussion on the receiver reverse unit functions included in sub- 
section 4. 1 was based upon the current Atlas /Centaur design. It therefore 
remains unchanged. 

Data Handling Subsystem Design Changes and Rationale 

Changes to the data handling subsystems in the probe bus/orblter 
spacecraft and the large and small probes are summarized below. 

For all four vehicles, the planned use of custom LSI was abandoned 
to achieve a lower cost design in light of the less severe mass and volume 
constraints upon the Atlas /Centaur design. 
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For the probe bus/orbiter spacecraft: 

1) Subsystem units which were previously dual units were separated 
into two identical redundant units in order to make them identical 
to existing OSO hardware; this results in a lower cost design- 
The slight Increase in mass and volume is felt to be acceptable 
in view of the less stringent mass constraints upon the Atlas/ 
Centaur design, 

Z) The remote multiplexers^ seven of which were previously 

required, are reduced to three dual units in order to be identical 
to existing OSO hardware; the reduction in the number of data 
inputs from Z24 to 192 still allows adequate spare inputs, and a 
lower cost, lower mass design is achieved, 

3) The orbiter data storage capacity was increased from 393 kilo- 
bits to 1 megabit because of increased storage requirements. 

In addition, the data storage unit is now divided into two identi- 
cal units (each 524 kilobits) in order to have graceful degradation 
of data storage capability; the added reliability justifies the mass 
penalty for the pair of storage units (about 70 percent greater 
mass than a single unit of the same capacity) in light of the 
increased mass allowances of the Atlas /Centaur design, 

4) A requirement for the orbiter mission of simultaneous dual path 
processing of data into two different formats at different bit rates 
resulted in about a 30 percent increase in the complexity of the 
telemetry processor. Dual path processing is required in order 
to be able to simultaneously transmit real time data at the maxi- 
mum downlink capability at periapsis (128 bps) and to store the 
remainder of the required science data for transmission when 
the link is not so constrained. 

5) The scheme for programming and selection of formats was 
changed. Initially, the capability for ground programming of 
two of several possible formats and selection between the two 
formats by real time or stored command was provided. 

Presently, l6 different formats are preprogrammed into read- 
only memory (ROM) elements, and selection of the desired 
format can be made by real time or stored command. This 
allows rapid changing among several formats, which is required 
during certain phases of the orbiter mission. Some flexibility 
of format programming is lost; however, the 16 format capa- 
bility exceeds the maximum requirement of 12 so that sufficient 
flexibility is still felt to exist. This change permitted about a 

10 percent reduction in the complexity of the telemetry processor. 
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6) An additional bit rate of 682. 7 bps (2 048/3) was added to the data 
handling subsystena capability in order to minimize the orbiter 
data storage requirement at periapsis- Previously, all bit rates 
in binary ratios' from 8 to 2048 bps were provided. Provision 
for the new bit rate requires a small amount of additional cir- 
cuitry to generate the signal, to command the change to that 
rate, and to signal users of that bit rate mode. 

For the probes (data handling portion of the command and data 
handling subsystem): 

1) The number of formats and structure of formats required for 
downlink data transmission and data storage were changed for 
both large and small probes. 

2) The data storage capacity was reduced in the large probe 
because of reduced storage requirements; in addition, the data 
storage element was changed from a RAM to a static shift 
register. 

3) The number of bit rates required for downlink data transmission 
and data storage has been increased. 

4) The number of data inputs required has been revised, allowing a 
reduction in multiplexer hardware. 

5) The biphase modulating subcarrier frequencies have been 
changed for both probes to accommodate the transponder 
interface. 

Data Handling Subsystem Trade Studies 

Each of the trade studies reported in subsection 4. 2, as it may be 
affected by the changes outlined above, is discussed below. 

Telemetry Data Recovery Analysis 

The material found in subsection 4.2 was written with the current 
Atlas/Centaur parameters included. 

Data Handling Interface Methods 

The interface definition summarized in subsection 4. 2 was not 
affected by the recent changes in program requirements. 

Orbiter Data Storage Analysis 

The data storage requirements for the orbiter spacecraft increased 
from approximately 393 kilobits to about 1 megabit as a result of the new 
science requirements and the new mission set. The original study was based 
upon memory capacities from 100 kilobits to 2 megabits; thus, the results of 
that study still apply to the present memory requirement. 
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Since magnetic tape recorders were not considered in the original 
study, it seemed appropriate to make a cursory investigation of their pos- 
sible application in light of the increased storage requirements. Data was 
gathered on more than 50 tape recorders and their characteristics were 
reviewed. It was determined that nnagnetic core is still preferred over a 
magnetic tape recorder since a core memory system has reliability, mass, 
and cost advantages for this application. This is primarily due to the fact 
that a tape recorder would need an additional buffer memory in order to 
accommodate the various bit rates required during data gathering and play- 
back; a core memory system can handle these multiple bit rates in a 
straightforward manner, has no moving parts, and does not require addi- 
tional interface buffering equipment. 

Probe Data Storage Hardware 

The data storage requirement on the large probe was reduced from 
4096 to Z048 bits as a result of a change in the probe descent profile and of 
the new science requirements. The conclusions made in the original study 
are still applicable. However, the 256-bit memory device chosen in that 
study will not be used because a preferred device will be space qualified 
for use on the probe bus/orbiter spacecraft; it can also be used on the 
probes and will allow a reduction in mass, power, and volume. This device 
is a low power, 512 bit static shift register. Although four of the devices 
will be needed to make up the Large probe memory, the individual package is 
quite small, and the serial-in/seriai-out data transfer is ideally suited for 
storing the serial bit stream in the large and small probes. 

Probe Stored Data Playback Techniques 


The results of the study to determine the optimum technique for 
playing back stored data in the probes were not affected by the recent 
changes in program requirements. 

Probe Multiple Data Formats 

Since the original study to determine the impact upon the probe data 
handling subsystems of providing two or more data formats, the need for 
multiple formats has been well established from an overall system stand- 
point. Input data sampling requirements are now well enough defined that 
it is possible to more thoroughly assess the impact of providing multiple 
formats. These new assessments are described below and can be used as 
guidelines for any additional format changes that may develop in the future. 

The Harris HPROM 1024 read only memory (ROM) chosen in the 
original study, a 1024 bit bipolar TTL -compatible device, is still felt to be 
the optimum choice for the format programming application. The ROM is 
organized as 256 words X 4 bits. In the current large probe baseline, pro- 
vision is made for 96 data Inputs. However, less than 12 of these inputs 
account for over 90 percent of the content of each data format. The 


6-16 



remainder of the inputs are "subcommutated" or sampled at a very low rate. 
Subcommutation results in complication of the data formatting design; how- 
ever, with the use of ROMs, complication of hardware is minimized. 

The basic telemetry frame requires two ROMs in order to provide 
an 8 bit output word. Five of the 8 bits are used to address up to 32 data 
inputs. The other three bits are used to tag a ROM output address word. 

The tag identifies whether the word defines an analog, serial digital, or 
bilevel discrete data input, whether a subcommutated input will be inserted 
into the basic frame, or whether a sync word will be inserted. 

Two additional ROMs are required for subcommutated inputs. Six 
of the eight output bits are used to address up to 64 subcommutated inputs; 
the remaining two are tag bits. 

Two 256 word X 4 bit ROMs can either accommodate a basic format 
of 256 words or other possible combinations such as two formats of 
128 words, four formats of 64 words, etc. Likewise, the ROMs used for 
subcommutated inputs can accommodate similar subcom frame formats. 

Thus, it can be seen that with four ROMs, which is the minimum 
number possible if subcommutation is necessary, four relatively complex 
data formats could be provided. Each of these formats could have a 
64 word basic frame and a 64 word subconn frame; the maximum possible 
total data frame for each format would be 4096 words (64 basic frames, 
each containing one word of the subcom frame). 

Providing up to four data formats can be done with minimal impact 
upon the probe design if the basic frame length and subcom frame length 
are kept to 64 words each. But, for example, if two basic frame formats 
of 128 words each were required, in general ROM elements would have to 
be added to provide more than those two formats. 

Although larger ROM elements are available, including a 
512 word X 8 bit MOS device which is presently space qualified by Hughes, 
the Harris HPROM 1024 is preferred. In addition to being space qualified, 
the Harris device is field programmable so that format changes, if necessary, 
can be made much later in the program than with the larger device, which is 
programmed early in its fabrication process. Moreover, the HPROM 1024 
is TTL compatible and packaged in a relatively small 16 pin unit, so overall 
packaging efficiency and cost are not significantly different than with the 
larger device. 

Probe Multiple Data Rates 


The results of this study, which was conducted to determine the 
impact upon the probe da^ handling subsystem of providing more than one 
data rate for downlink data transmission, were not affected by the recent 
changes in program requirements. 
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6. 3 SPACECRAFT COMMAND AND DATA HANDLING SUBSYSTEMS 


The Atlas /Centaur command and data handling subsystems are 
functionally quite similar to those described for Thor/Delta in Section 5, 
However^ there are a number of significant hardware design differences. 
These functional and hardware differences have been previously described 
in section 6 and subsection 6. 2. 

As with the Thor /Delta, the Atlas /Centaur command and data 
handling subsystems are highly modular in nature and are essentially 
identical on the probe bus and orbiter spacecraft. The few differences 
that exist are explained in the following discussions. 

Probe Bus/Orbiter Command Subsystem Functional Summary 

Figure 6-1 shows a block diagram of the command subsystem. It 
consists of four basic types of units, each employing a complete dual 
redundancy; command demodulators, central decoders, six single remote 
decoders, and pyro control units. The following is a brief description of 
the major functions performed by each of these units. 

Command Demodulator 


1) Receives and demodulates subcarrier into command data and 
clock signals 

2) Relays the data and clock signals to the central decoder 
Central Decoder 


1) Decodes and processes the incoming command data 

2) Performs a polynomial code check for command verification 

3) Provides storage for time dependent command sequences 

4) Initiates execution of the commands at the proper time 

5) Distributes commands, to the proper remote decoder 

6) Provides receiver reverse switching to select the connection 
combination between the receivers and antennas 

Remote Decoder 

1) Recognizes and decodes the appropriate command addresses 

2) Receives and decodes command data into pulse or magnitude 
commands 

3) Distributes pulse commands and magnitude data to spacecraft 
users (and to probes on the probe bus) 
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Pyro Control Unit 

1) Receives interlocked puLse commands from remote decoders 

2) Provides high current switching to fire pyrotechnic devices 

Table 6-12 summarizes the basic functional characteristics of the 
command subsystem for both the probe bus and orbiter spacecraft. As 
indicated in the table, the characteristics are identical. 


TABLE 6-12. PROBE BUS/ORBITER SPACECRAFT COMMAND 
SUBSYSTEM FUNCTIONAL CHARACTERISTICS SUMMARY 


Probe Bus and Orbiter 

Parameter Characteristics 


Command mode 

Command type 

Command initiation 

Command uplink 

Command word size 
Bit rate 
Modulation 

Probability of false command 

Number of pulse command outputs 

Number of magnitude command outputs 

Word size of magnitude commands 

Command storage capacity 

Resolution of command executions 

Number of pyrotechnic drivers 

Maximum delay between concurrent 
fire pulses 

Number of pyrotechnic initiators 
fired (capability) 


Real time or stored 
Pulse or magnitude 
Ground command, timer or event 

36 bits (includes 7 bit error code) 

4 bps 
PSK 

1 X 10“*^ 

192 

12 

16 bits 

2064 bits (86 words maximum) 
±125 ms (stored mode) 

5 redundant pairs 
0. 1 ms 

30 
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Probe Bua/Orbiter Command Subsystem Hardware Design Summary 


A summary of the hardware derivation and characteristics is shown in 
Table 6-13. In addition to presenting the mass, power, and volume character- 
istics for both the probe bus and orbiter spacecraft, the table briefly 
describes the source and type of hardware employed. 

As indicated in the table, three of the units are planned to be built by 
Hughes and utilize OSO designs. Of these units, the central decoder and 
remote decoder employ custom HSI circuit technology as a means for reduc- 
ing mass; the pyro control unit does not employ LSI since this technology is 
not as amenable to the high current pyrotechnic circuit applications. 

The command demodulator is planned to be purchased from Motorola. 
This unit is a modification of the command demodulator that was developed 
for the Viking Orbiter program: it utilizes MSI circuit technology. 

Probe Bus/Orbiter Command Subsystem Description 

Command Demodulator 


The command demodulator is a PSK demodulator and will be a 
purchased item. Initial indications are that the hardware will be a minor 
modification of one of the command demodulators used on the Viking program. 
It appears that, with such minor modifications, both the Viking lander and 
Viking orbiter command demodulators will meet the Pioneer Venus require- 
ments. A simplified block diagram of the command demodulator is shown in 
Figure 6-2, The receiver subcarrier input frequency will be between 200 
and 700 Hz. The data modulation will be at 4 bps. These frequencies are 
compatible with both the DSN and the Viking hardware. 

The command demodulator is operated as follows. When the receiver 
in lock signal is present, the unit will be turned on. When the signal to noise 
ratio from the receiver is high enough to provide a bit error rate less than 
10 ' 5 , the command demodulator will lock on to both the subcarrier and data 
signals, regenerate the clock and data, and provide an additional signal to 
enable the central decoder. Telemetry outputs will be supplied to provide an 
indication of the signal to noise ratio and the uplink bit rate. 

Central Decoder 


The central decoder will be a new design using many of the circuits 
from the OSO-I central decoder. The central decoder performs three basic 
functions: 1) real time processing of uplink commands, 2) stored time 

processing of commands from the command memory, and 3) receiver 
reverse algorithm implementation, A block diagram of the central decoder 
is shown in Figure 6-3, Operation is as follows. 
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TABLE 6-13. ATLAS/CENTAUR MODULAR COMMAND SUBSYSTEM HARDWARE 

DERIVATION AND CHARACTERISTICS 





Characteristic S'^ 



Probe Bus and Orbiter 
Derivation 

Mass 

— 

Power, 

W 

V olume 

Unit (Quantity) 

kg 

(lb) 

3 

cm 

(in ) 

Command demodulator (2) 

Motorola - POV 

(Uses 98 percent Viking 
orbiter circuits: MSI; PC 
Boards) 

2. 5 

( 5.6) 

3. 0 

3, 080 

(188) 

Central decoder (2) 

New design 

(Uses 50 percent OSO 
circuits: no new LSI; 
MICAM; * modules) 

4. 3 

( 9.4) 

3, 6 

6, 000 

(366) 

Command output module (6) 
(remote decoder) 

OSO 

(Six single units: 
existing LSI) 

1. 8 

( 4.2) 

1 

0. 3 

1, 720 

(105) 

Pyro control unit (2) 

New design 

(Uses 70 percent existing 
circuits: modules) 

1.2 

( 2.5) 

0 

4,260 

(260) 

Probe bus totals 


9. 8 

(21.7) 

6. 9 

15, 060 

(919) 

Orbiter totals 


9.8 

(21.7) 

6.9 

1 15,060 

(919) 


*MICAM is the acronym for Hughes "microelectronic assembly method. " 
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Real Time Processing . When the in-lock signal from the command 
demodulator is active, the real time processing section will be turned on. 

The demodulated data is accumulated in a register at the uplink bit rate until 
the first sync pattern is detected- If the sync pattern does not appear within 
a specified number of bit times after turn on, the unit is turned off. Upon 
receipt of the sync pattern, the accumulator will process the full command 
word if the central decoder address is correct. If the address is not correct, 
the accumulator will be cleared. Processing consists of a polynomial code 
check that detects all single and double bit errors and many other multiple 
bit errors. If the command is accepted, it is reformatted and transferred to 
either the stored memory for later processing, or the output section where 
it is encoded and transferred to a remote decoder. 

An accumulator counts the number of commands accepted In each 
command sequence. A check bit indicates if a command has been rejected. 
This information is relayed to earth in the telemetry data. 


Stored Time Processing . The stored command processor section 
(SCP) of the central decoder works as follows. The SCP memory is a long 
static shift register with multiple entry points- Three kinds of commands 
may be entered into storage: time delay, magnitude, and pulse. The com- 
mands are placed into memory after the polynomial code check and a decode 
that indicates the data is to be stored. The SCP is started into operation by 
a real time pulse command. Upon receipt of the start command, the data 
is shifted by a high speed clock to the most significant position of the com- 
mand memory, but not until the next major spacecraft clock transition. A 
word is then shifted out of storage; if it is decoded to be a pulse or magni- 
tude command, it is routed through the central decoder directly to a remote 
decoder. When the stored command word is a time delay, all processing 
from the SCP is stopped until the delay is counted out. The delay counter 
has 2^^ states and counts at a 8 Hz clock rate. Words can be processed at a 
maximum rate of one every 125 ms. At the end of the delay time, the next 
word is removed from the memory and the process is repeated. This timing 
process allows a series of commands separated by 125 ms to be processed 
with only one time delay command or a series of time delay commands could 
be cascaded to establish a very long delay. The only prerequisite for opera- 
tion is that the first word be a time delay command. 


An additional feature of the SCP allows verification of the memory 
contents via telemetry prior to starting the SCP- The memory must be in 
the "stopped’^ mode during this readout and recycling. 


Receiver Reverse Implementation . The receiver reverse function 
consists of a timer and logic that can provide three pulse outputs to change 
the connection between the antennas and receivers, and to disconnect the high 
gain antenna. The appropriate output is enabled upon the receipt of a pulse 
command or the count -out of the timer with a delay of about 32 h. The timer 
is reset if there is a polynomial code check verification (processing a com- 
mand) or when the output is commanded into either state. The timer can be 
defeated by commanding the same state of the antenna/receiver connection 
about every 30 h from either the real time link or in the stored command 

processor. 
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FIGURE 6-4. 
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Remote Decoders 


The remote decoders are from the OSO -1 program and do not have 
to be modified for the Pioneer Venus requir ements- The OSO remote 
decoder is designed to receive data over a single wire from either of two 
central decoders and distribute 4 NRZ serial magnitude signals and 64 pulse 
commands to users* The unit has been designed to provide adequate safe- 
guards to prevent false commands and spurious outputs* The unit is power 
strobed to minimize long term power requirements* 

The block diagram of the remote decoder is shown in Figure 6'-4. 
Operation is as follows* The input buffer accepts signals from the central 
decoders* It provides a data line output which is high whenever the input is 
in the logic 1 state or when a pulse command is to be transmitted. A 
memory element, which is activated by the data input, controls unit power. 
The remote decoder is deactivated by an internal command, after the pro- 
cessing has been completed, or by a pulse command from another unit. 

The Manchester decoder converts the incoming Manchester data into a 
serial NRZ format. It also provides the required clock and data signals on 
separate output lines. The initial condition portion of the circuit resets the 
remote decoder logic to prevent spurious outputs* An L-C oscillator is 
used to generate the timing reference needed for decoding Manchester data. 
The control and output logic decodes the address of the output and distributes 
pulse and magnitude commands to the addressed output line* 

Pyro Control Unit 

The block diagram of pyro control unit is shown in Figure 6-5. Each 
driver is capable of simultaneously firing three squibs* Each driver and the 
associated driver in the redundant unit, can be fired simultaneously for a 
total simultaneous drive capability of six squibs, or bridge wires* Interlocked 
commands are used to fire a squib; after arming the switch, the driver must 
be enabled within 1 sec in order to fire the squibs* When the timing interval 
is complete, the arming function is disarmed. 

The pyro control unit will be a new packaging design, with a large 
percentage of the circuits being similar to those from other programs. The 
simultaneity requirement to fire three squibs within 2 ms required a design 
that would drive a minimum current of 15 A into three 1 ohm pyrotechnic 
loads from the same driver. Because squib firing is irreversible, two inter- 
locked commands are used to fire a squib. Due to the high currents during 
firing, the squib circuits will be enabled only from the command memory; 
this will allow the maximum window between arming and firing commands to 
be set at less than a second, which will prevent any short circuits in the 
squibs or drivers from draining the battery for a longer time. 
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Probe Bus/Orblter Data Handling Subsystem Functional Summary 


A block diagram of the data handling subsystem is shown in 
Figure G-b. This subsystem consists of four basic types of units: dual 

remote multiplexers, PCM encoders, telemetry processors, and data 
storage units that are required only on the orbiter spacecraft. 

The PCM encoder and telemetry processor are redundant and fully 
crosstrapped to provide high reliability* Although the remote multiplexers 
are dual units, they are not used to provide complete dual redundancy. 
Redundancy is provided only for essential data inputs by cros strapping these 
data sources to other multiplexer inputs and sampling the data twice within 
each format. The reason for using two data storage units is twofold; first, 
it can provide full redundancy during the mission phases in which less than 
half of the total data storage is required; second, it provides graceful 
degradation during phases of the mission that require more than half of the 
data storage since, if one unit fails, 50 percent of the total capacity is still 
usable. 


The following is a brief description of the major functions performed 
by each of these units- 

Remote Multiplexer 

1) Accepts data from spacecraft subsystems and science 
instruments (and from probes on the probe bus) 

Z) ^Multiplexes analog, serial digital, and bilevel discrete input 
data onto a single output line to be transferred to the PCM 
encoder 

3) Receives address control data from the PCM encoder to provide 
channel selection 

4) Provides signals to data handling subsystem users to control the 
sampling of digital data 

PCM Encoder 


1) Accepts PAM analog data and serial digital telemetry data from 
remote multiplexers 

2) Digitizes analog data into 8 bit words and combines them with 
digital data into a PCM bit stream to be transferred to the 
telemetry processor 

3} Relays address control data from the telemetry processor to the 
remote multiplexers for channel selection 
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Telemetry Processor 


1) Provides a versatile telemetry frame format which is based upon 
16 preprogrammed formats which can be selected by real time 
or stored command. 

2) Provides capability for processing simultaneously two different 
data streams (data formats) and at different bit rates; one data 
stream (real time) is directed to the RK subsystem for trans- 
mission while the other data stream (stored-time) is directed to 
memory for storage- (This capability is used only on the orbiter 
spacecraft- ) 

3) Generates addresses of data inputs to be sampled- 

4) Encodes, modulates, and controls amplitude of PCM data and 
transfers it to the spacecraft transmitters or memory. 

Data Storage Unit 

1) Provides storage for scientific and engineering data oh the 
orbiter spacecraft. 

Table 6-14 presents a summary of the basic functional characteristics 
for the data handling subsystem. It shows the similarity and differences 
between the probe bus and orbiter spacecraft. As indicated in the table, the 
characteristics are identical with four exceptions. The major difference is 
that data storage is only required on the orbiter spacecraft: the other three 
differences concern the data formats. Only the telemetry processor is 
affected by these functional differences. In spite of these differences, the 
telemetry processor hardware is the same on the two spacecraft- 

Probe Bus /Orbiter Data Handling Subsystem Hardware Design Summary 

The derivation and characteristics of the data handling subsystem 
hardware are shown in Table 6-15. The table briefly describes the source 
and type of hardware employed, in addition to presenting the mass, power, 
and volume characteristics for both the probe bus and orbiter spacecraft. 

Three of the data handling units are planned to be built by Hughes. 

Of these units, the remote multiplexer and PCM encoder units are existing 
OSO units, whereas the telemetry processor is a new design that employs 
OSO circuits to a large degree. The remote multiplexer and telemetry 
processor employ a large amount of existing custom LSI circuitry as a 
means to reduce mass. 

The data storage unit is planned to be purchased from Electronic 
Memories. A previously designed core memory unit of the company's SEMS 
will be modified to meet the storage and interface requirements. 


6-31 



TABLE 6-14. PROBE BUS/ORBITER SPACECRAFT DATA HANDLING 
SUBSYSTEM FUNCTIONAL CHARACTERISTICS SUMMARY 


■ 

Characteristics 

Parameter 

Probe Bus 

Orbiter 

Word size, bits 



Number of data Inputs 

192 

A/D conversion accuracy 

±0. 4 per 

cent (8 bits) 

Data storage capacity, 

None 

1. 048 

megabits 



Data bit rates, bps 

8 to 2048 

Data formats 



Subframe length 

32 words 

Telemetry frame length 

512 words, 

16 subframes 

Number of preprogrammed i 

16 bus unique 

16 orbiter unique 

(ROM) 32 word subframes 



Number of downlink formats j 

16 bus unique 

16 orbiter unique 

Number of data storage l 

None 

16 

formats 



Error code 

Convolutional, 

length 32, rate 1/2 

Modulation type 

PCM/PSK 

Subcarrier frequency, Hz 

(TBD) 

(TBD) 
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TABLE 6-15. ATLAS/CENTAUR MODULAR DATA HANDLING SUBSYSTEM 
HARDWARE DERIVATION AND CHARACTERISTICS 



Derivation 

Character Lsfctcs^^" 




Mas s 

Power, 

W 

Volume 

Unit (Quantity) 

Probe Bus 

Orbiter 

kg 

lb 

cm 

, 3 
in 

Data input naoduLe (3) 
(remote multiplexer) 

OSO 

(Three dual units; 
existing LSI; PC 
boards) 

OSO 

(Three dual units; 
existing LSI; PC 
boards) 

I., 

2.4 

0. 4 

900 

55 

PCM encoder (Z) 

OSO 

OSO 

3. 1 

6. 8 

2. 6 

3, 510 

Z14 


(Two single units; 
existing MSI; 

MIC AM, "" PC 
boards, and 
modules ) 

(Two single units: 
existing MSI; 
MICAM,"* PC 
boards, and 
modules) 






Telemetry processor (Z) 

New design 

New design 

3. 6 

8. 0 

5. 7 

6, 770 

413 


(Uses 70 percent 
OSO circuits; no 
new LSI; MICAM 
and modules ) 

(Uses 70 percent 
OSO circuits; no 
new LSI; MICAM 
and modules) 






Data storage unit (Z) 

Not required 

Core memory- 
POV 

— 


— 

— 

— 



(Modified elec- 
tronic memories 
design) 

9. 1 

o 

o 

3. 0 

9, 630 

588- 

Probe bus totals 



7. 8 

17. 2 

8. 7 

11, 180 

682 

Orbiter totals 



16. 9 

37, Z 

11. 7 

20, 810 

1, 270 


*Where two sets of values are given, the bottom line is for the orbiter spacecraft. 
*=:=MICAM is the acronym for Hughes "microelectronic assembly method. " 
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Probe Bua/Orbiter Data Handling Subsystem Description 
Remote Multiplexers 


The remote multiplexer module is an existing design from the OSO-I 
program; it does not require any modification. 

A block diagram of this data input module is shown in Figure 6-7, 

It is basically a 32 input random access commutator with a single (but 
redundant) input control line and PAM output data line having an associated 
data return. The unit is capable of accepting high level analog data, parallel 
bilevel digital data, and serial digital data in various ratios. Upon request 
from the PCM encoder, analog data is multiplexed onto the PAM output line. 
Parallel bilevel data are sampled in 8 bit bytes and are gated to the output 
data line as an 8 bit serial word. Serial digital data is transferred to the 
unit in 8 bit bytes and is gated to the output data line through use of a gated 
read clock and read envelope signals which are provided by the remote 
multiplexer module. The input control line is used for both power on/off 
control and channel address information. The serial address into the unit 
is Manchester coded such that a coherent shift clock can be derived from 
the serial address, resulting in a single wire control. Sixteen read envelope 
signals are generated in synchronism with the sampling of each 8 bit serial 
or parallel digital word, thus informing the user that his data is being 
sampled. Serial data users must logically "AND" the read clock output with 
the appropriate read envelope signal to enable data readout. 

The multiplexer output is connected to a unity gain voltage follower 
amplifier for the purpose of presenting a high input impedance to the multi- 
plexer data sources while providing a low output impedance; thus, the noise 
susceptibility of the output PAM data line is minimized. The PCM encoder 
treats all data from a given remote multiplexer differentially with respect 
to each multiplexer reference ground, thus eliminating ground offsets 
between the data source and the PCM encoder's analog-to-digital converter. 

The multiplexer also contains six current switches that operate 
synchronously with the voltage switching gates. The purpose of the current 
switches is to commutate a precision constant current source (1. 000 mA) 
into the selected multiplexer channel; this feature thus provides signal con- 
ditioning of temperature sensors (such as thermistors or platinum resistors), 
pressure or position sensitive potentiometers, and other transducers 
directly. The current source is provided by the PCM encoder if this condi- 
tioning is required. 

The multiplexer configuration pins select the mode (i.e. , the channel 
assignments for the three types of input data) in which a particular multi- 
plexer is to be operated, 

PCM Encoder 


The PCM encoder is an existing design from the OSO-I program; it 
also does not require any modification. 
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A block diagram of the PCM encoder is shown in Figure 6-8. The 
unit accepts PAM analog and serial digital telemetry data from the remote 
multiplexers, processes and synchronizes the data, and generates a non- 
return to zero pulse code modulated (NRZ-Li/PCM) output bit stream to the 
telemetry processor. Analog-to -digital conversion of the remote multi- 
plexer analog data is also provided. The PCM encoder relays the necessary 
address control data from the telemetry processors to the remote multi- 
plexers for channel selection. The PCM encoder also provides regulated 
power and on/off commanding of the remote multiplexers. Primary timing 
and control of the PCM encoder is derived from the Manchester coded (split 
phase) instruction address provided by the telemetry processors. 

The remote multiplexer decoder circuit decodes the remote select 
bits and gates the output and power control pulses onto the appropriate out- 
put control lines whenever remote multiplexer power control commands 
are received. 

The multiplexer differentially multiplexes the PAM data and return 
from the remotes into the A/D comparator. It also steers a precision 
1, 000 mA constant current source to individual output lines. A calibration 
resistor, which is wired to the unit connector for transducer calibration, 
can be wired to a remote multiplexer telemetry input for calibration of the 
current source. 

The analog -to-digital converter accepts the PAM input data from the 
remote multiplexers and encodes it into a serial 8 bit digital equivalent of 
the high level analog data (MSB outputted first) or behaves as a fixed thresh- 
old detector for making one -zero decisions on the incoming digital data. 

The treatment of the data (as analog or digital) is controlled by the A/D bit 
in the input control word. 

If digital data is to be processed, the comparator is forced to a con- 
stant 2. 56 V reference. Thus, the comparator registers a logic 1 for data 
above this voltage and a logical 0 for data below this voltage. 

All power supplies for the PCM encoder are generated internally 
from the spacecraft 28 V bus. A series regulator provides regulation of the 
bus voltage and an electronic conversion unit (ECU) generates all of the sup- 
ply voltages required by the unit, including power to be distributed to the 
remote multiplexers. 

Telemetry Processor 

A block diagram of the telemetry processor unit is shown in Fig- . 
ure 6-‘9. The unit is a new packaging design but uses a large number of 
existing OSO circuits. It provides three basic functions: spacecraft clock 

and timing signals, real time processing and stored format processing. 

Operation of the telemetry processor is briefly described below. 
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Spacecraft Clock, The oscillator and countdown circuits provide 
timing for the spacecraft subsystems and science instruments. In addition 
to various clock signals, a time code generator accumulates time and 
transfers the data into the telemetry stream upon request from the format 
generator. 

Real Time Processing . Real time processing is accomplished by 
selection of a format viiT^he Command subsystem and configuration con- 
troller. The same path is used to select the bit rate, output voltage level, 
and convolution encoder bypass operation. The format and address informa- 
tion are in the read only memory and, upon selection, address information 
is fed to the address formatter and relayed to the PCM encoder. Data 
returned from the PCM encoder is routed to the convolution encoder and 
biphase modulator. It is then amplitude controlled and mixed with data 
from the probes (probe bus only) and sent to the RF subsystem. 

Stored Format Processing . Stored format processing is used only on the 
orbiter spacecraft. It is accomplished by using a parallel path with real 
time processing, except there are separate time slots provided in order to 
time share the same remote multiplexers. Stored time data received from 
the PCM encoder is separated from real time data and fed to the data stor- 
age unit via the memory control. 

Data Storage Unit 

The orbiter spacecraft data storage unit will be a purchased item. 

The baseline is a magnetic core memory. The memory will be constructed 
in two equal sections, each with half of the required mission capacity. 
Because the total memory is not redundant, failure of one half of the memory 
will allow graceful degradation by allowing much of the data to be recovered. 


6.4 PROBE COMMAND AND DATA HANDLING SUBSYSTEMS 

The Atlas /Centaur command and data handling subsystem for the 
probes are functionally quite similar to those previously described for 
Thor/Delta in Section 5. However, there are a number of significant hard- 
ware design differences, the primary one being that custom LSI circuit 
technology is not employed in this Atlas /Centaur version of the subsystems. 
The major hardware and functional differences were previously described 
in section 6 and subsystem 6,2. Differences in requirements were described 
in subsection 6. 1; the principal differences are in the magnitude of certain 
requirements such as number of data inputs, sample rates, bit rates, data 
storage bits, number of commands, and pyrotechnic initiators fired. 

As with the Thor /Delta design, the command and data handling 
functions are combined into a single subsystem in both the large and small 
probes. The subsystems are functionally quite similar on the two vehicles; 
the differences between the probes are explained in the following discussion. 
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Command and Data Handling Subsystem Functloaal Summary 


Figure 6-10 is a functional block diagram of the command and data 
handling subsystems; it represents the subsystems for both the large and 
small probes, although their physical designs are different. The subsystems 
are divided into two control items or units; the command data unit and the 
pyro control unit. The following is a brief description of the major functions 
performed by these subsystems. 

The command portion of the subsystem does the following: 

1) Accepts pulse and magnitude commands from the probe bus 
spacecraft for preseparation tests and for initialization of the 
probe’s cruise timer 

2) Provides an accurate timer to initiate probe preentry sequences 
after a 20 to 23 day cruise period 

3) Provides pulse command outputs to probe subsystems and 
scientific instruments based upon predetermined (stored) 
sequences and real time events 

4) Detects pressure and acceleration events during descent to 
initiate certain command sequences 

5) Provides, high current switching capability for commanded 
firing of pyrotechnic devices. 

The data handling portion of the subsystem does the following; 

1) 'Accepts analog, bilevel discrete, and serial digital data from 

the probe subsystems and science instruments 

2) Digitizes analog data into 10 bit serial words 

3) Formats all data according to one of several stored formats 

4) Convolutionaily encodes and biphase modulates the PCM data 

5) Provides for data storage during entry blackout. 

Table 6-16 summarizes the basic functional characteristics of the 
command and data handling portions of the subsystems for the large and 
small probes. As indicated in the table, many of the characteristics are 
identical for both probes. The differences that exist are primarily due to 
the fact that the small probe is essentially a subset of the large probe; 
the small probe requires less command and data handling activities to 
satisfy its mission requirements. 
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TABLE 6-16. LARGE/SMALL PROBE COMMAND AND DATA HANDLING 
SUBSYSTEMS FUNCTIONAL CHARACTERISTICS SUMMARY 


Parameter 


Characteristic & 


Large Probe 


Small Probe 


Command 

Cruise timer 
Range 

Stability (0^ to 40®C) 

Resolution 
Descent timer 
Range 

stability (-20° to +65°C> 

Resolution 
Command mode 
Comnnand type 
Command initiation 
Number of event inputs 
Number of command outputs 
Total command executions 

Number of pyrotechnic drivers 

Maximum delay between con- 
current fire pulses 

Number of pyro initiators fired 
(capability) 

Number of acceleration detection 
switches 

Number of pressure detection 
switche s 

Data handling 

Word size, bits 
Number of analog inputs 

> 

10 bit accuracy 

8 bit accuracy/10 bit resolution 
Number of digital inputs 
10 bit serial 
Bilevel discrete 
Data storage capacity, bits 
Number of data formats 

Data bit rates, bps 

Error coding 
Modulation type 
Subcarrier frequency, Hz 




Z4 days 


48 


1 X 10 (20 sec in 23 days) 

2 sec 


13.6 min {between recycle) 
5 X lO'^ 

0. 1 sec 
Stored 
Pulse 

Time or event 

8 

I 

256 


4 redundant pairs, multiple 
2 redundant pairs , single 
10 nonredundant, single 


38 

2 

2 


16 

32 

16 
32 
2 04S 


|160 or 80 
1 20 (store only) 


3 redundant pairs, multiple 
0. 1 ms 
18 
2 
2 

10 

8 
24 

8 
24 
512 

60 or 30 or 10 


20, 480 


Convolutional, length 3 2, rate 1/2 
PCM/PSK 

I 30, 720 
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Command and Data Handling Subsystem Hardware Design Siimmary 

A summary of the hardware derivation and characteristics for the 
command and data handling subsystems is shown in Table 6-17. In addition 
to presenting the mass, power, and volume characteristics for the units in 
both the large and small probes, the table briefly describes the source and 
type of hardware employed* Wherever practicable, the units make use of 
presently qualified components, utilize existing designs, and employ com- 
mon designs between the Large and small probe subsystems; these features 
ail contribute to a lower cost design* 

New design will be undertaken for the command/data units on both 
probes. There are two principal reasons for not using existing command 
and data handling hardware. First, certain performance requirements, 
such as the 10 bit analog -to -digital conversion accuracy required, and 
certain environmental constraints, such as the high deceleration experi- 
enced upon entering the Venus atmosphere, are not readily met by existing 
equipment, thus requiring some cost to modify the equipment and possibly 
some redesign* The second reason is that the advantage of using a custom 
design in the relatively small probe vehicles, from a mass and volume 
standpoint, becomes apparent when one considers that any inefficiency is 
multiplied by a factor of four, the total number of probes. The latter con- 
sideration is also important in the decision to make the small probe design 
customized rather than forcing the larger capability of the large probe 
command/data unit upon each of the three small probes. It is important to 
note, however, that a great deal of commonality is employed between the 
large and small probe designs in order to minimize design costs. 

The pyro control units contain squib drivers of a new design, each of 
which is capable of simultaneously firing three squibs. Because of the Large 
number of pyrotechnic initiators on the probes, the use of the multiple squib 
driver results in a considerable mass and volume reduction. Cost is mini- 
mized due to the fact that the designs used for the probe bus/orbiter space- 
craft and the large and small probes are nearly identical, the principal 
difference being in the packaging design* 

Command/ Data Unit Description 

The command/ date unit performs all command and data handling func 
tions with the exception of firing pyrotechnic devices, which is done by the 
PCU. Figure 6-11 is a detailed block diagram of the command/ data unit and 
is applicable to both the large and small probes. Maximum commonality of 
design is used between the two probes. Differences in hardware exist in the 
number of multiplexer elements, the number of memory elements used for 
data storage, format programming, and command sequencing circuitry, and 
in the number of command decoding and output buffering elements. The rela 
tive magnitude of the difference in hardware can be seen by reference to 
Tables 6-16 and 6-17. 

The command/ data unit can be functionally divided into the command 
section and the data handling section, each of which is described below. 
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TABLE 6-17, ATLAS/CENTAUR PROBE COMMAND AND DATA HANDLING SUBSYSTEM 
HARDWARE DERIVATION AND CHARACTERISTICS 





Characteristics 



' 

Mass 

Power 

Cruise/De scent, 
W 

V olume 

Unit 


Derivation 


lb 

3 

cm 

. 3 

in 

Large probe 








Command/data unit 

New design, existing technology: 
MICAM/^ PC boards, and modules 

1.95 

4. 3 

0. 04/8. 3 

2720 

166 

Pyro control unit 

New design, existing technology: 

50 percent probe bus circuits: modules 

1. 18 

2.6 

(transient only) 

1330 

81 

Acceleration switches (2) 

. 

"(1) Existing design: space qualified 
(1) Existing design; must be space 
qualified 

0.23 

0, 5 


66 

4. 0 

Pressure switches (2) 

Existing design, high reliability: 
must be space qualified 

0. 18 

0.4 

— 

25 

1.5 

Total 



3. 54 

7. 8 

0. 04/8. 3 

4140 

253 

Small probe 








1 

Command/data unit 

- 

New circuit design; 70 percent large 
probe circuits 

New product design; MICAM,''' PC 
boards and modules 

1. 54 

3. 4 

0. 04/4. 6 

2280 

139 

Regulator unit 

New package; existing circuit design; 
modules 

0. 18 

0, 4 

0. 0/1. 2 

197 

12 

Pyro control unit 


New circuit design; 80 percent large 
probe circuits 

^New product design; modules 

0. 55 

1,2 

(transient only) 

361 

22 

Acceleration switches (2) 


|(1) Same as large probe; space 
1 qualified 

(1) Existing design; must be space 
L qualified 

0. 23 

0. 5 


66 

4. 0 

Pressure switches (2) 


[(1) Same as large probe 
(1) Existing design, high reliability; 
t must be space qualified 

0. 18 

0. 4 


25 

1.5 

Total 



2. 68 

U1 

vO 

0. 04/5. 8 

2930 

179 


'i'MICAM is the acronym £or Hughes ’'microelectronic assembly method," 
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FIGURE 6-11. LARGE AND SMALL PROBES COMMAND/DATA UNIT 
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Command Section 


The command section of the probe command and data handling 
subsystem receives pulse and magnitude commands from the probe bus 
prior to separation of the two vehicles- These commands are used to start 
or stop preseparation tests, to provide a ZO bit time code to the probers 
cruise timer, and to start the timer which, in turn, initiates preentry 
events with an accuracy of ±Z0 sec following a nominal ZO day cruise period. 
After separation of the probes from the probe bus, all pulse commands 
generated by the command section result from fixed stored commands or 
from '^evenf occurrences signaled by probe subsystems and science instru- 
ments- No magnitude commands are provided by the probe command 
section- 

The command memory has the capacity to store 64 output commands 
and 256 individual command executions which are programmed into a read 
only memory prior to unit assembly. Stored commands are activated by 
either time or events. The delays are programmed by time tags stored as 
part of the command word in memory. These time tags are referenced to 
the probe's descent timer for execution timing control. All time tagged 
commands will be executed relative to special event occurrences such as 
acceleration or pressure switch closures. When an event occurs or when 
time coincidence occurs between the stored command time tag and the 
binary state of the descent timer, stored commands are processed through 
the command decoder- One of two timer resolution modes is commanded 
internally. In the high resolution mode, conrmand execution can be provided 
with a resolution of less than 100 ms. In the low resolution mode, which is 
used for most of the descent phase of the probe mission, command execution 
is provided with a resolution of less then 800 ms. 

One of the large probe science instruments, the neutral mass 
spectrometer (NMS), requires squib firing commands which are independent 
of probe acceleration sensing or atmospheric pressure sensing. Since all 
stored command executions during entry and descent are relative to these 
two parameters, NMS valve ON/OFF commands will be generated indepen- 
dent of the stored command sequencer; they are initiated upon receipt of 
serial pulses from the NMS instrument. 

Standard pulse command outputs from the decoder are used to acti- 
vate squib driver circuits for firing of the pyrotechnic squibs associated with 
probe operations and with the science instruments. A two command sequence 
is required for squib firing; the first command applies unregulated power to 
arm all squib drivers in the pyrotechnic control unit; the second is a unique 
command pulse to fire individual squib drivers. 

The primary interface between the command section and the using 
subsystems and science Instruments is at the output of the command decoder- 
The decoder is deenergized during the 20 day cruise period, except during 
postseparation test (approximately 10 min) and during a brief interval 2 days 
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prior to entry. It is turned ON by the application of power to the command 
section, which is controlled by the cruise timer after separation. The 
decoder is energized for the entire descent phase beginning 15 min prior to 
entry , 


Only one command output is independent of the command decoder; the 
’’Engineer ing -ON‘^ command normally generated by the cruise timer and 
which results in activating the power switches in the probers power subsystem. 
Ail command section circuits, with the exception of the cruise timer and 
regulator, are powered from the switched, unregulated bus and thus are 
deenergized until the Engineering-ON command is executed. 

An additional interface between the command subsystem and the 
using subsystems and payload instruments is via event signals. These sig- 
nals originate as pulse outputs from the using subsystems and instruments 
and are sent to the command section to initiate time sequenced commands. 
Time sequenced commands are executed at preprogrammed times relative 
to the occurrence of these event signals. The command section has provi- 
sions for eight different event signals and associated event initiated com- 
mand sequences. Provision is made to accept ten serial pulses on a single 
input and to provide asynchronous firing of 10 NMS valve squibs independently 
of the command memory and descent timer. 

Pulse command outputs are grouped within the command section in 
multiples of 16 signals. Each group is referenced to its own isolated sig- 
nal return, which can be made available to users who utilize all 16 pulse 
commands of a single group. A group divided among many users will have 
its return tied to the command section signal ground. In either case, the 
transmission of a logical ”1” relies upon the eventual commonality of the 
command section signal ground and the user^s signal ground (i.e. , a return 
path for the pulse command current via a system or ’’unipoint” ground). 

Noise immunity provided by the standard input buffer (discussed in the com- 
mand subsystem interface definition of subsection 4, 1) is sufficient so that 
providing command signal returns to users is unusually unnecessary. These 
returns are not provided unless abnormally high voltage differentials exist 
between the command section signal ground and the user's ground. 

Data Handling Section 


The data handling section of the command and data handling subsystem 
accepts analog, serial digital, and bilevel discrete data from probe subsys- 
tems and science instruments. It digitizes the analog data and formats all 
data into a serial bit stream. Formatting is accomplished by use of ROM 
elements; multiple formats are provided to improve the efficiency of down- 
link data transmission. Accelerometer data is stored during the high 
deceleration experienced upon initial encounter with the Venus atmosphere; 
it is later played back and formatted with real time data to be transmitted to 
earth. The data handling section convolutionally encodes the serial data bit 
stream and biphase modulates it before transferring it to the communications 


6-47 


RELAY T 



FIGURE 6-12. LARGE PROBE PYRO CONTROL UNIT 
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subsystem (and the probe bus prior to separation)* Timing signals are 
provided to probe subsystems and instruments in order to synchronize 
transfer of data or other operations with the data handling section. 

The data handling multiplexer has 96 input channels in the large probe 
and 64 input channels in the small probe* The distribution of analog, bilevel 
digital, and aerial digital channels was given in Table 6-6* The multiplexer 
provides special circuitry for certain analog inputs requiring high accuracy 
analog-to -digital (A/D) conversion. The A/D converter in the data handling 
section converts the sampled analog data into a 10 bit serial digital word 
format. Within the full scale A/D conversion range, specified input signals 
will be converted with an accuracy of ±5 mV or ±0. 1 percent of full scale 
(±Z. 5 mV offset and ±2. 5 mV quantization error). Ail other analog inputs 
will be converted with 10 bit resolution, but with ±20 mV or ±0. 4 percent of 
full scale accuracy (±17.5 mV offset and ±2,5 mV quantization error). 

PCU Description 


The PCU accepts pulse commands from the command/data unit and 
provides high current solid state switches to switch unregulated bus current 
to probe subsystem and instrument pyrotechnic devices. Bus voltage to the 
current drivers is switched ON and OFF by relays. The relays serve a 
two-fold purpose: they function as switches to ensure safe and 

reliable pyrotechnic firing and they block leakage current to the PCU during 
the probe 20 day cruise so as to eliminate any drain on the battery other 
than that required for the cruise timer. 

All pyrotechnic operations, with the sole exception of the neutral 
mass spectrometer (NMS) ON/OFF valves, have redundant arming switches 
and firing switches in the PCU. The NMS has ten pyrotechnic valves which 
will not be provided with redundant arming or firing. 

Large Probe PCU 


The large probe PCU provides firing pulses to 38 pyrotechnic 
initiators. Twenty -two drivers are included in the PCU; each of eight of 
these drivers has the capability of simultaneously firing three squibs; and 
14 drivers have single squib firing capability. Figure 6-12 is a block dia- 
gram of the large probe PCU. 

Small Probe PCU 


The small probe PCU provides firing pulses to 14 pyrotechnic 
initiators. Six drivers are included in the PCU; they each have the capa- 
bility of firing three squibs simultaneously, although four of them are 
presently only required to fire two squibs simultaneously- Figure 6-13 
is a block diagram of the small probe PCU. 
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